Scrivi quindi ottimizza o scrivi ottimizzato [duplicato]

Esiste una semplice regola di ordine di tre:

1. fallo bene . La correttezza è fondamentale, qualcosa che fa la cosa sbagliata in fretta o in bellezza è inutile. Questo deve andare più in profondità di "oh questo sembra funzionare bene" - deve funzionare in modo affidabile per l'intero dominio di applicazioni per il quale si intende utilizzare il codice.
2. Scaricalo . L'eleganza e la semplicità del codice sono importanti. È probabile che il codice scritto sotto 1 abbia diverse proprietà di tipo prototipo. In questa fase potresti essere in grado di ridurre drasticamente la quantità di codice da 1, renderla molto più semplice o entrambe. Avere un codice facile da comprendere, ben documentato, elegante rende più facile passare al passaggio successivo. Quello che spesso accade anche qui è che si può individuare un'ottimizzazione algoritmica per risolvere lo stesso problema con la stessa correttezza. Queste ottimizzazioni algoritmiche sono in genere molto più pulite, migliori e più efficaci rispetto alle ottimizzazioni di livello molto basso del metallo.
3. Scarica velocemente . Ora che sai che funziona, e come funziona ed è ben documentato, dai un'occhiata per vedere se è necessario renderlo più veloce. Di solito non lo farai - vedi la risposta di Florian sotto. Solo se hai assolutamente bisogno di ottimizzare (usa un profiler!), Lo fai ora. Stai iniziando da un codice bello e ben documentato. Probabilmente finirai con un codice arcano meno bello se la stai davvero ottimizzando - ma va bene, è documentato, e hai anche la bellissima versione nella cronologia VCS a cui fare riferimento.

La regola generale è questa (sottolineatura mia):

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

-- Donald E. Knuth, "Structured Programming with go to Statements"

Ora, questo non significa che dovresti scrivere un codice inefficiente. Dovresti scrivere un codice efficiente se non ci vuole molto più tempo del codice inefficiente. Se è possibile eseguire 1 richiesta SQL anziché 100, si prega di farlo. Se non ti ci vuole molto più tempo, cioè.

Questo codice potrebbe non essere usato molto spesso, quindi in realtà non è affatto un collo di bottiglia, anche se potrebbe sembrare inefficiente. Se scriverlo in modo efficiente significa passare troppo tempo, non c'è alcun valore aggiunto per la tua attività.

Quindi, ovviamente, se devi ottimizzare qualcosa perché è lento, non dimenticare mai prima il profilo.

Alcuni link che potrebbero interessarti:

• È sempre sbagliato ottimizzare prima profiling?
• La micro-ottimizzazione è importante per la codifica?

Stai suggerendo di fare un'ottimizzazione prematura?

Il codice è veloce quando corrisponde ai requisiti non funzionali relativi alle prestazioni. Fino a quando tali requisiti non sono soddisfatti, non devi preoccuparti delle prestazioni: ci sono cose molto più importanti di cui preoccuparsi, come la qualità del tuo codice, l'architettura, ecc.

Una volta che il requisito di prestazioni non funzionali viene interrotto dal codice, significa che è più lento di ciò che è accettabile / desiderabile. A questo punto, dovresti:

• Verifica il tuo codice (invece di indovinare dove si trova il collo di bottiglia, dato che ci sbagliamo sempre),

• Ottimizzalo finché il test corrispondente al requisito non passa di nuovo.

Scrivi ottimizzato quando sai per certo che avrà un effetto ed è giustificato dalla leggibilità del codice.