Quali sono le buone pratiche per eseguire l'ottimizzazione basata sul software?

L'ottimizzazione è sempre buona: tutto ciò che devi fare è ottimizzare la metrica corretta.

Di solito, vale la pena assumere il costo delle ottimizzazioni e il guadagno - quanto costa (in termini di salario del programmatore) ottimizzare? Quanto incide sui ricavi?

Alcuni esempi (forzati):

• Un file batch che sposta alcuni file doc dal computer della segreteria a un server locale una volta alla settimana. Potrebbero volerci 1 ora, a nessuno importa. Importante è scrivere lo script.

• Un codec video. Elaborerà miliardi di pixel per tutta la sua durata e verrà eseguito su dispositivi embedded, con risorse molto limitate. Se è lento, anche se fa abbastanza bene il suo lavoro, sarà sostituito. Quindi, una squadra di guru ne scriverà una buona parte in ASM, e con cura riordina manualmente le istruzioni per ottenere alcuni cicli di clock.

• Qualche codice back-end di Facebook. Se funziona il 10% più velocemente, eliminerà il 10% della bolletta energetica dei data center, che si estende a miliardi di $.

• Un sistema di messaggistica (Skype, Gmail, ecc.) è usato da milioni. Se è pigro, tutti si lamenteranno. Perdi quote di mercato. Vale la pena investire anni-uomo per ottimizzare.

• Un'app per la contabilità Java, sviluppata per la tua azienda, probabilmente utilizzata da poche persone hundead. Sarà più economico acquistare due computer in più rispetto a una settimana di ottimizzazione.

Nel contesto delle applicazioni web, ci sono due ragioni principali per ottimizzare:

• Quando la tua app / sito rallenta al di sotto delle aspettative degli utenti
• Quando il tuo server diventa sovraccarico, ed è più economico ottimizzare rispetto all'acquisto di nuove macchine.

Ovviamente non è sempre una cattiva idea. Se lo fosse, potresti semplicemente usare generare-e-test per ogni calcolo (o anche randomizzare e pregare) e dipendere da hardware più veloce per fare il lavoro in meno rispetto ai tuoi programmatori. E infatti, in questo momento il pendolo sta oscillando verso l'ottimizzazione del software, poiché le velocità del processore raw sono altissime e l'efficiente codifica multi-thread sta diventando molto più importante di quanto sia mai stata.

Detto questo, è sempre il caso che comprare una macchina più veloce sia in definitiva più economico di un ugolare il tuo codice contorcendolo nel nome della performance. È necessario essere consapevoli delle pressioni che influenzeranno il trade-of in un modo o nell'altro.

• Più a lungo sarà necessario mantenere il codice, più soffrirà di codice contorto e incomprensibile. (Si noti che questo è non uguale alla longevità .. Una routine di ordinamento in un sistema operativo potrebbe essere scritta una volta, dimostrata corretta per tutti gli input e quindi letteralmente mai più modificata. il tempo di ottimizzare e finire con un codice orribile ha senso.)

• Ovviamente, è necessario conoscere il costo dei programmatori, il costo dell'hardware e almeno un'idea di quanto debito tecnico si sta accumulando, ovvero quanto tempo di manutenzione aumenterà con codice più complicato. Questo può variare enormemente tra i singoli programmatori, quindi effettivamente conoscere la tua gente è sorprendentemente importante.

• mai supporre. Misura sempre. Sapere se l'ottimizzazione che stai meditando migliorerà effettivamente le cose e da quanto. Se questo significa che devi scrivere una grande quantità di codice che potrebbe dover essere rimosso di nuovo, così sia. Alla fine, sei ancora in vantaggio perché hai una maggiore conoscenza del tuo sistema e con una certa cura, tali esperimenti possono informare i tuoi prossimi esperimenti e in realtà farti risparmiare tempo quando viene visualizzata una domanda simile.

Per evitare il debito tecnico, l'importante è limitare l'impatto di qualsiasi cosa tu cambi; un livello di accesso ai dati è grande, ma con incapsulamento appropriato può avere effetti solo sul livello di accesso ai dati, quindi almeno si conosce il limite di quanto debito si può accumulare tutto ciò che viene detto. Trovare alcune routine che mangiano il 90% del tuo tempo e cambiarne solo quelle è ancora meglio (e molto spesso tali routine esistono). Un potente profiler è tuo amico qui.

Dipende da ciò che causa effettivamente i problemi di prestazioni. I problemi di prestazioni appaiono in tutti i tipi di forme e dimensioni e hai effettivamente corretto i colli di bottiglia reali?

IMHO poche ore con uno strumento di query profiler e taskmgr / top può risolvere il 90% dei problemi di prestazioni del database. Alcuni indici aggiuntivi, query di ristrutturazione o aggiunta di memorizzazione nella cache possono fare un'enorme differenza.

Anche se aggiungi altro hardware potresti trovare che il tuo design dell'applicazione non può usarlo. Se è a collo di bottiglia, più hardware non può aiutarti.

In primo luogo, perché l'ottimizzazione basata sul software dovrebbe essere una cattiva idea?

Quando distribuisci servizi Web che hanno le loro prestazioni dettate più dalle tecnologie sottostanti rispetto al codice stesso, allora potrebbe essere discutibile concentrarsi sull'ottimizzazione del proprio codice in termini di codice. Tuttavia, tieni presente che, come per qualsiasi tipo di ottimizzazione, devi profilare la perfromance del target. Se il collo di bottiglia si trova nelle tecnologie utilizzate, allora trovi le alternative o prova a trovare il modo di fare meno affidamento su di esse con attività cruciali per le prestazioni.

In generale, direi che "il lancio di hardware è più economico" è un modo di pensare molto stupido. Con tale atteggiamento, non solo sei pigro e irresponsabile, ma chiudi anche le persone con meno risorse hardware. Naturalmente questo potrebbe essere un po 'diverso in prospettiva di applicazioni web che funzionano su hardware dedcated, dove tale atteggiamento potrebbe non essere così ingannevole come con il software distribuito dal client.

So is software based optimization always a bad idea?

No. Né è sempre male, non sempre bene. Tuttavia, l'ottimizzazione che descrivi - il livello più basso non sarebbe il modo migliore per farlo.

Generalmente trascorrendo numerose ore di sviluppo per raddoppiare la percentuale di tempo di esecuzione in caso di app Web è uno spreco di denaro. D'altra parte, dedicare tempo a renderlo scalabile ed eliminare il codice con una complessità temporale non ottimale potrebbe valerne la pena.

Devi tenere a mente che, a meno che la tua applicazione non sia progettata per essere scalabile, non sarai in grado di aggiungere facilmente più hardware. Se parti del codice hanno una complessità di tempo ridicola, l'aggiunta di hardware non aiuterà a gestire la crescita.

Un'altra cosa è che in molti casi, piuttosto che ottimizzare il codice, devi ottimizzare l'architettura .