Il modo migliore per misurare la velocità di funzioni, classi e processi

Question

Qual è il modo migliore per misurare la velocità delle funzioni e delle classi? Per ogni funzione ci sono varie soluzioni e vorrei sapere come misurare la velocità di corsa e ottimizzare le mie lezioni condivise con la migliore soluzione possibile.

Inoltre, come si misura la velocità SQL, ad esempio differenze tra procedure memorizzate, selezioni, viste e ecc.?

Answer 1

Hai due opzioni.

Uso System.Diagnostics.Stopwatch per metodi specifici.

Questo è un timer ad alta risoluzione in .NET che è possibile utilizzare per parti specifiche del codice.

Usa un profiler se è necessario misurare le prestazioni per l'intera applicazione.

È possibile utilizzare la build in Profiler di Ultra Edition di Visual Studio o uno strumento come Eqatec.

Answer 2

Sei meglio usare un profiler. Il problema con la misurazione del tempo di esecuzione di Wallclock (come fatto da Stopwatch classe) è che è influenzato da molti fattori lontani dal tuo controllo. Per menzionare solo alcuni di questi fattori, esiste una rete e altre latenza I/O e decisioni di programmazione del sistema operativo che influenzano la priorità relativa di applicazioni e thread. Se stai correndo all'interno di un ambiente virtualizzato, ciò può anche avere un effetto relativamente grande sulle misurazioni del tempo di Wallclock a raggio di millisecondi. Il profiler non sarà perfetto, ma ti darà un'idea migliore di quanto tempo viene effettivamente trascorso a eseguire il tuo codice.

Oltre a ciò, un buon profiler può spesso darti anche altre metriche utili, come la memoria utilizzata dal tuo codice durante l'esecuzione.

Answer 3

È meglio non confondere gli obiettivi di misurazione e ottimizzazione. Sono compiti diversi. Misurare, mentre è buono per quantificare i risultati della correzione di qualcosa, è scarso nel dirti cosa correggere.

Per quanto riguarda la misurazione, se voglio fare una presentazione di quanto velocemente è qualcosa, voglio un ambiente controllato e un buon cronometro. Tuttavia, allo scopo di ottimizzare, le misurazioni grezze (come l'esecuzione di qualcosa di 1000 volte) e l'utilizzo di un semplice timer, sono più che buone.

Per quanto riguarda l'ottimizzazione, non mi occupo della velocità. Sono preoccupato per un'attività inutile. Non è necessario eseguire il codice ad alta velocità per trovarlo.

Quando qualsiasi programma esegue, traccia un albero di chiamata. L'ottimizzazione consiste nella rimozione di quante foglie (istruzioni) e più frutta (I/O) possibile. Un buon modo per farlo è potare interi rami.

• In tutti tranne i programmi più piccoli, le tipiche opportunità di ottimizzazione consistono in punti di chiamata (righe di codice in cui vengono chiamate funzioni, non le funzioni stesse) che, quando si realizzano quanta parte degli alberi di chiamata da loro, potrebbero davvero essere fatti un altro modo. Una singola linea di codice dall'aspetto innocente potrebbe essere responsabile di una grande frazione dell'intero albero e potresti essere semplicemente in grado di tagliarlo.

Per trovarli, penso che il campionamento dello stack di tempo a parete sia il modo migliore. Non è necessario che questo sia un processo efficiente e un numero piuttosto piccolo di campioni funziona altrettanto bene (o meglio) rispetto a un gran numero di campioni. È necessario farlo ripetutamente, perché ogni dato programma, come scritto per la prima volta, non contiene solo un'opportunità per SpeedUp. Ne contiene diversi.Ecco un esempio.