Tutti pazzi per le prestazioni

di Gianni Tomasicchio - 26 gennaio 2009

E’ da quando ho iniziato a programmare che mi scontro con i patiti delle prestazioni. “Questa procedura è più performante se la riscriviamo così”, oppure “il ciclo while è più veloce del ciclo for”, e ancora “se mettiamo tutto su un’unica riga risparmiamo due variabili”, ecc. ecc..

Ho notato che questa attenzione alle prestazioni si fa quasi malattia in alcuni sviluppatori PHP, professionisti e neofiti. Nei forum ad esempio si trovano spesso domande del tipo “quale approccio è più performante?” ma anche nei blog di illustri sviluppatori ci si imbatte in discussioni sulla velocità di esecuzione di questa o quella funzione. Per non parlare degli articoli di approfondimento che promettono di svelare i segreti sull’ottimizzazione degli script PHP.

Ma siamo tutti impazziti?

Uno dei padri della programmazione, Donald Knuth, ha scritto:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Insomma, nel 97% dei casi non ci dovremmo preoccupare dell’efficienza del nostro codice, rischieremmo di fare solo danni. Quali?

La prima vittima dell’ottimizzazione sfrenata e la leggibilità del codice. Magari quando lo scrivete sapete cosa fa e come funziona, ma fra un mese, un anno? Quanto tempo perderete per capire a cosa servono quelle righe di codice che ricordano un manoscritto aramaico? Se la leggibilità è compromessa allora la manutenzione risulta più costosa.

Per ottimizzare poi si rischia di mettere in secondo piano tutti i buoni principi di programmazione: separazione delle competenze, design modulare, basso accoppiamento del codice, eliminazione delle ridondanze, applicazione dei design pattern, ecc.

E se tutto ciò non vi basta, avete notato che stranamente quando si fanno discorsi sulle prestazioni degli script spesso non ci sono dati oggettivi, misurati scientificamente? Come si può parlare di velocità senza avere neanche due numeri da confrontare? Forse certe affermazioni sull’ottimizzazione del codice sono fatte con troppa leggerezza, al solo scopo di spacciarsi per esperti?

Non sto negando che una applicazione possa essere “lenta” ma per prima cosa bisognerebbe capire quanto è lenta, attraverso una misura espressa in secondi, ed anche quando è lenta, ovvero in che condizioni si verificano i problemi di prestazioni. Insomma prima di parlare di ottimizzazione bisognerebbe individuare e misurare le circostanze nelle quali si verificano dei rallentamenti percepibili dall’utente.

Servono quindi strumenti affidabili, come i benchmark (es.: Apache AB) ed i profiler (es.: XDebug), per fare analisi dettagliate in modo da circoscrivere le situazioni critiche, ammesso che ce ne siano! E’ una attività che non andrebbe fatta durante lo sviluppo ma solo quando i test funzionali evidenziano prestazioni mediocri.

Un’altro errore è pensare che i problemi di prestazioni vadano risolti soltanto attraverso un intervento sul codice. Si sottovaluta così la funzione dei sistemisti. Un server ben carrozzato ed ottimizzato, sul quale è installato un PHP accelerator, può fornire dei miglioramenti prestazionali di gran lunga superiori a quelli generalmente ottenibili con un’ottimizzazione del codice. Se volete farvi un’idea a riguardo, in questo articolo viene valutato l’impatto di alcuni acceleratori per PHP su Drupal, ottenendo performance medie triplicate. Senza toccare una riga di codice.

1 commento

1 andy larchitetto giovedě 19 febbraio 2009, ore 13:58
concordo con l'articolo...

più d'una volta il cosiddetto codice "ottimizzato" è stato solo un modo per far lavorare male chi dopo magari deve modificare qualcosa...
mi è capitato ad esempio di vedere cose del genere:

if (condizione) istr;
else istr;

a parte la lettura del codice, ma mettere le parentesi {} non penso rallenti le prestazioni dello script...
sarebbe molto meglio leggere un qualcosa del tipo (con spazi annessi):

if (condizione) {

istr;

} else {

istr;

}

altri casi ad esempio (in java soprattutto) che si ha un set di un oggetto che come parametro si ritrova un'altra serie di get e parametri passati... istanziare nuovi oggetti o creare nuova variabili non migliorerebbe la lettura e l'eventuale manutenzione, anzichè poi dopo dover per forza di cose capire e "smontare" quest'unica, mastodontica istruzione?
Effettua l'accesso o registrati per inserire un commento