Spesso è importante capire non solo il perchè il nostro applicativo software è lento, poco performante, pesante nell'esecuzione di uno o più task. E' necessario capirne il quando, il quanto e il dove.
E' pratica comune aprire il nostro editor, seguire riga per riga il codice del nostro algoritmo in debug e provare a risolvere quello che è, o ci sembra, il problema che determina il rallentamento del nostro applicativo software.
I più allenati, coloro che hanno una esperienza tale nel vedere quel che noi magari non vediamo, riescono a scovare più o meno facilmente, istruzioni e/o porzioni di codice che per la loro natura implementativa, hanno un apporto di complessità da attenzionare. E che per il modo in cui questi costrutti sono (erroneamente) impiegati, influenzano negativamente il nostro codice e di conseguenza il nostro applicativo in fase di esecuzione.
A naso, capirne il quando può sembrare semplice: "quando viene eseguita la procedura X, è più lento rispetto a quando è eseguita la procedura Y". Allora, debugghiamo la procedura X e cerchiamo di venirne a capo. In questo modo abbiamo anche dato probabilmente una risposta anche al dove: nella procedura X.
Ma è vero?
Può darsi. A volte si, altre no. Spesso, no.
Però, e c'è un però, potrebbe anche essere che questa lentezza si manifesti nell'ambito di esecuzione di una procedura più complessa. O che la lentezza della nostra procedura, è frutto di lentezze derivanti da procedure e funzioni che da essa sono eseguite per il compimento del task.
Una analisi strumentale delle performance del nostro applicativo software, ci permette di analizzare in maniera oggettiva, le criticità insite nel nostro codice; dandoci altresì, un grosso aiuto nel dare le risposte sul quando, quanto e dove le criticità si manifestano.
ProDelphi è uno di quei tool che ci permette di profilare il nostro codice sorgente, eseguirlo ed ottenere misurazioni relative alla complessità intesa come percentuale di runtime di ogni metodo e tempo di esecuzione dello stesso.
Grazie al report generato da ProDelphi, è possibile analizzare le performance dei singoli metodi (colonne in rosso) o dei metodi come 'sommatoria' di metodi childs necessari alla esecuzione del task (colonne in blu).
Dal report è possibile rispondere alle nostre domande sul dove: il nome del metodo; il quanto: dal numero di Calls e dal tempo di RunTime RT-SUM.
Per conoscere il dove, è interessante l'analisi del report di dettaglio di ogni metodo:
con esso siamo in grado di analizzare da dove provengono le chiamate al metodo in esame (metodi in verde) e quali metodi invoca il metodo in esame durante la sua esecuzione (metodi in blu). Per ognuno di essi, abbiamo informazioni circa il numero di invocazioni e il tempo di esecuzione.
A completamento dell'informazione esposta con questo grafico, abbiamo una piccola view di fianco nella quale è rappresentata la Critical Path, ovvero il Path più complesso in termini di esecuzione che ha nel nostro metodo in esami la radice.
#CodingLikeACoder
