martedì 23 settembre 2014

MONITORARE I TEMPI DI ESECUZIONE DELLE FUNZIONI (DOTNET)

Come è possibile stabilire se un algoritmo o istruzione sia più performante di un altro? Il framework .Net mette a disposizione alcuni utili strumenti per aiutare il programmatore ad analizzare il codice.



Introduzione

In un articolo precedente facevo riferimento al fatto che l'utilizzo delle espressioni regolari per controllare i caratteri, rispetto ad utilizzare un confronto ciclico, non fosse più performante (anzi, quasi il contrario). Come sono arrivato a questa conclusione?


In questo articolo viene fatto riferimento ad una serie di istruzioni da utilizzare all'interno del codice sorgente di una applicazione (in-code). Gli IDE, come Microsoft Visual Studio e molti altri, mettono a disposizione strumenti per l'analisi prestazionale del codice sorgente (profiler), tuttavia non è argomento di questo articolo trattare come e quali tools possono essere utilizzati; vi invito a farmi sapere se siete interessati ad un articolo dedicato a questo argomento.


La classe Stopwatch

La classe System.Diagnostics.Stopwatch può essere utilizzata per "contare" il tempo di esecuzione da un certo punto del codice ad un altro. Dato che il tempo di esecuzione di un programma non è statisticamente identico, quindi il risultato dovrà essere calcolato tramite una media, questo è causato dal fatto che il codice viene eseguito all'interno di una sandbox del framework a sua volta eseguito da un sistema operativo con gestione di thread autonoma).
Detto questo è indispensabile far notare che, nel risultato finale, viene compreso anche il tempo di esecuzione richiesto per utilizzare le funzioni della classe Stopwatch!

Come?

Il codice proposto in esempio aiuta a monitorare una determinata funzione.

Conclusione

Abbiamo visto un codice molto utile su come monitorare i tempi di esecuzione di determinate funzioni all'interno del codice. Il risultato prodotto da questa analisi è comunque dipendente da alcuni fattori come le caratteristiche Hardware, la situazione dei thread attivi e gestiti dal Sistema Operativo al momento dell'esecuzione del codice e le istruzioni precaricate in RAM dalla virtual machine CLR.

Adottare questa soluzione a volta porta dei vantaggi rispetto ad usare profiler, in quanto questi frammenti di codice sono scritti nel sorgente e possono essere lasciati a scopo di debug all'interno di release.

fonti

Nessun commento:

Posta un commento