La cultura della programmazione è cambiata considerevolmente dai tempi in cui C era il linguaggio scelto e l'hardware era così insignificante che C era effettivamente una necessità.
Fortunatamente, non dobbiamo preoccuparci troppo dell'ottimizzazione al giorno d'oggi. La regola generale è di mai ottimizzare a meno che tu non abbia una buona ragione per farlo. E per avere una buona ragione, devi:
-
Avere un requisito prestazionale per il tuo prodotto, qualcosa come "il tempo di risposta del server deve essere inferiore a 200 millisecondi". (Requisiti vaghi come "il più velocemente possibile" sono generalmente disapprovati).
-
Misura l'effettivo tempo di risposta del tuo server e effettivamente testimone che non soddisfa il requisito.
-
esaurisci tutte le opzioni per soddisfare il requisito riconfigurando il tuo sistema per farlo funzionare in modo più ottimale. (Sareste sorpresi: alcune persone non conoscono la differenza tra l'esecuzione di un server Web in modalità di debug e in modalità di produzione.)
-
esaurisci tutte le opzioni per soddisfare il requisito acquistando hardware migliore e / o altro hardware . Al giorno d'oggi l'hardware in genere costa molto meno degli stipendi degli sviluppatori.
-
Getta il profiler sul tuo sistema e stabilisci che il collo di bottiglia è in realtà nel codice di cui sei responsabile e hai il potere di cambiare.
-
esaurisci tutte le opzioni per ottimizzazioni algoritmiche . (Introduzione di un livello di memorizzazione nella cache da qualche parte; codice di ristrutturazione in modo che qualcosa accada in modo asincrono piuttosto che in modo sincrono ; ecc.)
Quindi, e solo allora, è consigliabile tentare la fortuna modificando il codice per farlo funzionare in modo più ottimale. E come puoi immaginare, non raggiungiamo quasi mai questo stadio.