Quando l'ottimizzazione non è prematura e quindi non è malvagia?

"L'ottimizzazione precoce è la radice di tutti i mali" è qualcosa che quasi tutti noi abbiamo sentito / letto. Ciò che mi incuriosisce di quale tipo di ottimizzazione non è prematuro, ovvero in ogni fase dello sviluppo del software (progettazione di alto livello, progettazione dettagliata, implementazione di alto livello, implementazione dettagliata ecc.) Qual è l'entità dell'ottimizzazione che possiamo considerare senza che si passi al lato oscuro.

Quando lo stai basando sull'esperienza? Non male. "Ogni volta che abbiamo fatto X, abbiamo subito un brutto colpo di prestazione. Pianifichiamo di ottimizzare o evitare X interamente questa volta."

Quando è relativamente indolore? Non male. "L'implementazione di questo come Foo o Bar richiederà altrettanto lavoro, ma in teoria Bar dovrebbe essere molto più efficiente. Facciamolo."

Quando stai evitando algoritmi schifosi che si ridimensioneranno terribilmente? Non male. "Il nostro responsabile tecnico afferma che il nostro algoritmo di selezione del percorso proposto viene eseguito in tempi fattoriali; non sono sicuro di cosa significhi, ma lei suggerisce che ci impegniamo seppuku anche solo per considerarlo. Consideriamo qualcos'altro."

Il male deriva dallo spendere un sacco di tempo e problemi di risoluzione dell'energia che non conosci realmente esistono. Quando i problemi sicuramente esistono, o quando i fantasmi psudo-problemi possono essere risolti a buon mercato, il male scompare.

Steve314 e Matthieu M. sollevano punti nei commenti che dovrebbero essere considerati. Fondamentalmente, alcune varietà di ottimizzazioni "indolore" semplicemente non ne valgono la pena, perché il banale aggiornamento delle prestazioni che offrono non vale l'offuscamento del codice, stanno duplicando i miglioramenti che il compilatore sta già eseguendo, o entrambi. Vedi i commenti per alcuni esempi di non miglioramenti troppo intelligenti della metà.

Il codice dell'applicazione dovrebbe essere solo il necessario, ma il codice della libreria dovrebbe essere il più buono possibile, poiché non si sa mai come verrà utilizzata la libreria. Quindi, quando scrivi il codice della libreria, deve essere buono sotto tutti gli aspetti, sia esso prestazioni, robustezza o qualsiasi altra categoria.

Inoltre, devi pensare alle prestazioni quando progetti la tua applicazione e quando scegli gli algoritmi . Se non è progettato per essere performante, nessun livello di hacker può renderlo performante in seguito e nessuna micro-ottimizzazione supererà un algoritmo superiore.

che tipo di ottimizzazione non è prematura

Il tipo che deriva da problemi noti.

Quando l'ottimizzazione non è prematura e quindi non è malvagia?

È difficile dire cosa sia il bene e il male. Chi ha questo diritto? Se guardiamo alla natura, sembra che siamo programmati per la sopravvivenza con un'ampia definizione di "sopravvivenza" che include il passaggio dei nostri geni alla prole.

Quindi direi, almeno secondo le nostre funzioni e programmazioni di base, che l'ottimizzazione non è malvagia quando si allinea all'obiettivo della riproduzione. Per i ragazzi, ci sono le bionde, le brune, le teste rosse, molte adorabili. Per le ragazze, ci sono ragazzi e alcuni sembrano stare bene.

Forse dovremmo essere ottimisti verso quello scopo, e lì aiuta a usare un profiler. Il profiler ti consentirà di stabilire le priorità delle ottimizzazioni e del tempo in modo più efficace, oltre a fornirti informazioni dettagliate sugli hotspot e sul motivo per cui si verificano. Questo ti darà più tempo libero speso per la riproduzione e la sua ricerca.

Il preventivo completo definisce quando l'ottimizzazione non è prematura:

Un buon programmatore non si crogiolerà in tale compiacimento, sarà saggio guardare attentamente il codice critico; ma solo dopo che quel codice è stato identificato . [enfasi mia]

È possibile identificare il codice critico in molti modi: strutture o algoritmi di dati critici (ad esempio, utilizzati pesantemente o il "nucleo" del progetto) possono fornire importanti ottimizzazioni, molte ottimizzazioni minori vengono identificate tramite i profilatori e così via.

Devi sempre scegliere una soluzione "abbastanza buona" in tutti i casi in base alle tue esperienze.

Il detto di ottimizzazione si riferisce alla scrittura di "codice più complesso di" abbastanza buono "per renderlo più veloce" prima di sapere effettivamente che è necessario, quindi rendere il codice più complesso del necessario. La complessità è ciò che rende le cose difficili, quindi non è una buona cosa.

Ciò significa che non dovresti scegliere un super complesso "puoi ordinare i file da 100 Gb scambiando in modo trasparente su disco" la routine di ordinamento quando un ordinamento semplice farà, ma dovresti anche fare una buona scelta per l'ordinamento semplice in primo luogo. Scegliere ciecamente Bubble Sort o "selezionare tutte le voci in modo casuale e vedere se sono in ordine. Ripetere." è raramente buono.

La mia regola generale: se non sei sicuro di aver bisogno dell'ottimizzazione, supponi di no. Ma tienilo a mente quando devi ottimizzare. Ci sono alcuni problemi che puoi conoscere in anticipo però. Questo di solito comporta la scelta di buoni algoritmi e strutture di dati. Ad esempio, se è necessario verificare l'appartenenza a una raccolta, si può essere abbastanza sicuri di aver bisogno di un qualche tipo di struttura di dati impostata.

Nella mia esperienza, nella fase di implementazione dettagliata la risposta sta nella profilazione del codice. È importante sapere cosa deve essere più veloce e cosa è accettabilmente veloce.

È anche importante sapere esattamente dove si trova il collo di bottiglia delle prestazioni: l'ottimizzazione di una parte del codice che richiede solo il 5% del tempo totale per l'esecuzione non farà nulla di buono.

I passaggi 2 e 3 descrivono l'ottimizzazione non prematura:

1. Fallo funzionare
2. Test. Non abbastanza veloce? Profilalo .
3. Utilizzando i dati del passaggio 2, ottimizza le sezioni più lente del codice.

Non si tratta di ottimizzazione quando si scelgono cose che sono difficili da cambiare, ad esempio: piattaforma hardware.

La scelta delle strutture di dati è un buon esempio, fondamentale per soddisfare i requisiti sia funzionali che non funzionali (prestazioni). Non facilmente modificabile e tuttavia guiderà tutto il resto nella tua app. Le tue strutture dati cambiano gli algoritmi disponibili ecc.

Conosco solo un modo per rispondere a questa domanda, e cioè fare esperienza nell'ottimizzazione delle prestazioni. Ciò significa: scrivere programmi e, dopo averli scritti, trovare gli speedups in essi e farlo in modo iterativo. Ecco un esempio.

Ecco l'errore che molte persone commettono: cercano di ottimizzare il programma prima di eseguirlo. Se hanno frequentato un corso di programmazione (da un professore che in realtà non ha molta esperienza pratica) avranno gli occhiali colorati Big-O, e penseranno che è di questo che si tratta . È lo stesso problema, l'ottimizzazione preventiva. **

Qualcuno ha detto: prima fai la cosa giusta, poi fai in fretta. Avevano ragione.

Ma ora per il kicker: se lo hai fatto un paio di volte, riconosci le cose sciocche che hai fatto in precedenza che causano problemi di velocità, quindi istintivamente le eviti. (Cose come rendere la struttura della tua classe troppo pesante, essere inondato di notifiche, confondere le dimensioni delle chiamate di funzione con il loro costo in tempo, l'elenco potrebbe continuare all'infinito ...) Le eviti istintivamente, ma indovina come si presenta al meno- esperto: ottimizzazione prematura!

Quindi questi sciocchi dibattiti continuano all'infinito :)

** Un'altra cosa che dicono è che non devi più preoccupartene, perché i compilatori sono così buoni e le macchine sono così veloci al giorno d'oggi. (KIWI - Kill It With Iron.) Non ci sono accelerazioni esponenziali dell'hardware o del sistema (eseguite da ingegneri molto intelligenti che lavorano sodo) che possono eventualmente compensare rallentamenti esponenziali del software (eseguiti da programmatori che la pensano in questo modo).

Quando le esigenze o il mercato lo richiedono specificamente.

Ad esempio, le prestazioni sono un requisito nella maggior parte delle applicazioni finanziarie perché la bassa latenza è cruciale. A seconda della natura dello strumento scambiato, l'ottimizzazione può passare dall'uso di algoritmi non bloccanti in un linguaggio di alto livello all'utilizzo di un linguaggio di basso livello e persino dall'estremo - implementando gli algoritmi di corrispondenza dell'ordine nell'hardware stesso (usando FPGA per esempio ).

Un altro esempio potrebbe essere alcuni tipi di dispositivi integrati. Prendiamo ad esempio il freno ABS; in primo luogo c'è la sicurezza, quando si colpisce la pausa l'auto dovrebbe rallentare. Ma c'è anche una prestazione, non vorresti alcun ritardo quando colpisci la pausa.

La maggior parte delle persone chiamerebbe l'ottimizzazione prematura, se stai ottimizzando qualcosa che non si traduce in un "errore soft" (funziona ma è ancora inutile) del sistema a causa delle prestazioni.

Esempi del mondo reale.

• Se il mio ordinamento a bolle impiega 20 ms per essere eseguito, ottimizzarlo a 1 ms quicksort non migliorerà l'utilità generale in alcun modo significativo nonostante sia un aumento delle prestazioni del 2000%.

• Se una pagina Web impiega 20 secondi per caricarsi e la riduciamo a 1 secondo, ciò può aumentare l'utilità del sito Web da 0 a quasi infinito. Fondamentalmente qualcosa che è stato rotto perché troppo lento, ora è utile.

Che tipo di ottimizzazione non è prematura?

Un'ottimizzazione che risolve un problema di prestazioni noto con l'applicazione o un'ottimizzazione che consente all'applicazione di soddisfare criteri di accettazione ben definiti.

Una volta identificato, è necessario dedicare un po 'di tempo per stabilire la correzione e misurare il vantaggio in termini di prestazioni.

(cioè non è - "Penso che questo pezzetto di codice possa sembrare lento, cambierò X per usare Y invece e sarà più veloce").

Ho riscontrato molte "ottimizzazioni" premature che alla fine hanno rallentato il codice - in questo caso, prendo prematuro per significare "non pensato". Le prestazioni devono essere confrontate prima e dopo l'ottimizzazione e deve essere mantenuto solo il codice che effettivamente migliora le prestazioni.

"L'ottimizzazione prematura è la radice di tutti i mali" è qualcosa che quasi tutti noi abbiamo sentito / letto

Vero. Sfortunatamente è anche una delle citazioni di programmazione più (maliziosamente) abusate di tutti i tempi. Dato che Donald Knuth ha coniato il meme vale la pena aggiungere un po 'di contesto originale dalla citazione:

Dobbiamo dimenticare le piccole efficienze, diciamo circa il 97% delle volte: l'ottimizzazione prematura è la radice di tutti i mali. Tuttavia non dovremmo rinunciare alle nostre opportunità in quel 3% critico. ... Un buon programmatore ... sarà saggio esaminare attentamente il codice critico; ma solo dopo che quel codice è stato identificato. ... l'esperienza universale dei programmatori che hanno utilizzato strumenti di misurazione è stata che le loro ipotesi intuitive falliscono

Si noti che Knuth ha parlato specificamente della velocità di esecuzione in fase di esecuzione .

I programmatori sprecano enormi quantità di tempo pensando o preoccupandosi della velocità delle parti non critiche dei loro programmi.

Inoltre, ha scritto l'articolo nel 1974, quando qualsiasi risorsa di macchina in cui la correlazione premium e negativa tra la velocità di esecuzione e la manutenibilità del programma (maggiore velocità - meno gestibile) era probabilmente più forte di adesso.

OK, per rispondere alla tua domanda, secondo Donald Knuth, l'ottimizzazione NON è prematura se corregge un grave collo di bottiglia delle prestazioni che è stato identificato (idealmente misurato e individuato durante la profilazione).

Come ho detto prima, "l'ottimizzazione prematura" è uno dei meme più maltrattati, quindi la risposta non sarà completa senza alcuni esempi di cose che non sono ottimizzazioni premature ma a volte vengono scrollate di dosso come tali:

• strozzature che sono visibili ad occhio nudo e possono essere evitate prima di essere introdotte come O (N ^ 2) numero di roundtrip al database con N grande dove esiste un'alternativa O (1)

Inoltre non sono nemmeno correlati alla velocità di esecuzione del runtime:

• design premuroso in anticipo

• digitazione statica (!)

• ecc. / qualsiasi forma di sforzo mentale