L'ottimizzazione prematura è sempre negativa? [duplicare]

IMO, "ottimizzare prematuramente" è solo negativo se riduce la leggibilità. La programmazione tende ad essere un'attività di lettura una sola lettura, e se le tue ottimizzazioni rendono il codice molto più difficile da capire, sarei preoccupato.

Direi che lo sforzo richiesto per il refactoring del tuo codice non varrebbe i benefici (in termini commerciali), ma è sorprendente ciò che il commento dispari fa per migliorare la chiarezza del codice. Ciò è particolarmente vero per il codice "insolito" (ad esempio le ottimizzazioni di cui si preoccupa).

Sebbene questa domanda abbia avuto risposta, l'IMO, il principale inconveniente dell'ottimizzazione prematura, è il tempo sprecato sia inizialmente che durante l'ottimizzazione senza le necessarie informazioni sulle prestazioni e anche le (frequenti) riscritture perché, mentre si concentra sull'ottimizzazione, l'implementazione è andata di stucco. Di nuovo IMO penso che non sia una buona pratica di programmazione.

Sembra che ciò che chiami ottimizzazione sia ciò che chiamo angoli di taglio.

Se si sta davvero ottimizzando, allora c'è una sola risposta: documentala bene.

Se stai tagliando le curve, allora spetta a te vedere dove i benefici superano i rischi, essere pronto a giustificare o cambiare quell'abitudine se non è giustificabile (secondo te ... finché non ottieni coinvolto con gli altri e quindi utilizzare la peer review come stick di misurazione).

Quando parli di microottimizzazioni, cercando di spremere fino all'ultimo nanosecondo per quel ciclo, spesso non vale la pena. Quando si lavora su un'applicazione web / database, assicurarsi che le interazioni del database siano più o meno ottimali, ma soprattutto, assicurarsi che si scalino. A meno che tu non stia lavorando su codice ad alte prestazioni, elaborazione di dati scientifici o qualcosa del genere, altre ottimizzazioni procedurali non ti aiuteranno molto.

L'ottimizzazione senza profilazione è sempre tempo e amp; sprecato energia. Sparando nel buio. Roba voodoo. Bad.

Prima di eseguire l'ottimizzazione, fai il profilo e / o l'analisi per assicurarti che:

• In realtà hai un problema di prestazioni

e

• Sai dove il collo di bottiglia è

Non provare a indovinare. Misura due volte, taglia una volta.

E dopo aver ottimizzato, ripeti il profilo per assicurarti di aver risolto il problema.

Nei piccoli negozi molti sviluppatori sono anche i designer e gli analisti. Quando hai un quadro più ampio (ho appena detto questo?) Del problema, abbiamo maggiori probabilità di pianificare in anticipo. Se si comporta male, è una riflessione diretta su di te poiché sei l'unico programmatore.

Limitare il tempo di stima può essere un piccolo trucco per farti accelerare e interrompere qualsiasi sviluppo non necessario. Lo farà qualsiasi calcio nei pantaloni.

Allo stato attuale

Ha sempre funzionato per te per farlo? "Se non è rotto, non aggiustarlo" è un'altra regola d'oro che dovrei attenermi a più. Mi ha causato un sacco di mal di testa quando non mi sono attenuto. Non può mai causare un problema, ma chi lo sa.

Come è stato detto prima "fai la cosa più semplice che possa funzionare". Ho trovato le regole di Pike sulla programmazione per essere molto illuminante.

Cosa considerare

Suppongo che tu intenda per lo più l'ottimizzazione della velocità. Perché c'è anche l'ottimizzazione per la leggibilità, la dimensione ...

L'ottimizzazione prematura è sempre negativa, perché:

• Ci vuole tempo per ottimizzare. Potresti passare questo tempo facendo qualcosa di meglio; per esempio, chiamando la tua ragazza;).
• L'ottimizzazione di solito significa rendere le cose più concrete.
• Molto probabilmente non sarà leggibile da altri programmatori. Ogni programmatore dovrebbe conoscere semplici algoritmi, quindi se c'è qualcosa di più complesso, perderà tempo a sconvolgere ciò che significa; ridurrà il livello basso, analizzando più informazioni e molto probabilmente facendo errori nella comprensione del codice ottimizzato.
• È stato detto da Donnald Knuth, che è l'autorità per la programmazione e se sostiene che qualcosa è in qualche modo è quasi certamente così.
• Devi misurare prima dove è il tuo sistema lento e quindi ottimizzare. Non il contrario. Ad esempio il motore di Quake ha usato la stringa di confronto O (N) per cercare le variabili invece dell'hashing O (1), ha usato il linguaggio script Quake C che ha ottenuto circa il 10% delle sue prestazioni e il "famoso" PVS è semplice hashing O (1) con semplice compressione (la visibilità è precalcolata, ogni sezione del mondo per ogni sezione quindi ciò che gli oggetti sono visibili è ottenuta attraverso una ricerca di mappa hash e poiché tale informazione è enorme nella memoria è compressa). Il libro nero di programmazione grafica di Michael Abrash è pieno di esempi e esempi di "misura prima" dove ha sbagliato a valutare cosa fosse problema (capitolo 17

Ma l'ottimizzazione prematura non è sempre negativa, perché:

• Ci sono casi in cui, ottimizzando, puoi vedere una soluzione migliore. Ma è di più su una possibilità.

Quindi devi valutare i pro e i contro delle ottimizzazioni premature.

Penso che, poiché siamo tutti persone, devi solo masterizzarti poche volte con ottimizzazioni premature per smettere di usarle.

La citazione di Knuth si trova in un contesto in cui è previsto che tu scriva come un buon codice che puoi in primo luogo . La parte relativa all'ottimizzazione è quella in cui cedi il buon codice per ottenere un incremento prestazionale atteso, scrivendo meno codice chiaro o fai trucchi intelligenti.

Di solito non è una buona idea, dato che raramente sai quando sarà necessario in anticipo - questo è il lavoro del profiler per dirti - così finisci con codice sub-ottimale senza alcun beneficio.

Nota che "il miglior codice possibile" potrebbe essere un normale trucchetto che nella tua esperienza è comunque necessario, ma poi è il tuo lavoro documentare queste cose per il futuro.

È la mia esperienza che i compilatori fanno un ottimo lavoro nel creare un buon codice per un codice buono e semplice, ma possono essere confusi dal codice intelligente. Il codice smart ha il suo posto per risolvere i problemi (runtime o compilatore saggio) ma non esagerare.