È possibile utilizzare il cronometro nel codice di produzione?

Question

Ho bisogno di un timer preciso, e DateTime.Ora sembra non abbastanza preciso. Dalle descrizioni che ho letto, System.Diagnostics.Stopwatch sembra essere esattamente quello che voglio.

Ma ho una fobia. Sono nervoso sull'utilizzo di qualsiasi cosa da System.Diagnostics nel codice di produzione effettivo. (Lo uso estensivamente per il debugging con Assert e PrintLns ecc, ma non ancora per le produzioni.) Non sto semplicemente cercando di usare un timer per confrontare le mie funzioni - la mia app ha bisogno di un timer reale. Ho letto su un altro forum che System.Diagnostics.StopWatch è solo per il benchmarking, e non dovrebbe essere usato nel codice di vendita al dettaglio, anche se non è stato fornito alcun motivo. È corretto, o sono io (e chi ha postato quel consiglio) che sono troppo chiuso a System.Diagnostics? cioè, va bene usare System.Diagnostics.Stopwatch nel codice di produzione? Grazie Adrian

Answer 1

Sotto il cofano, praticamente tutto ciò che fa il cronometro è il QueryPerformanceCounter. A quanto ho capito, Stopwatch è lì per fornire l'accesso al timer ad alta risoluzione - se hai bisogno di questa risoluzione nel codice di produzione non vedo nulla di sbagliato nell'usarlo.

Answer 2

Afaik StopWatch è una shell con funzionalità QueryPerformanceCounter. Questa funzione è alla base di molte misurazioni relative ai contatori delle prestazioni. QPF è molto veloce da chiamare e perfettamente sicuro. Se ti senti paranoico sullo spazio dei nomi di Diagnostics, pInvoke the QPF direttamente.

Answer 3

Il cronometro è basically a neat wrapper nei metodi nativi QueryPerformanceCounter e QueryPerformanceFrequency. Se non ti senti a tuo agio con lo spazio dei nomi System.Diagnostic, puoi access these directly.

L'utilizzo del contatore delle prestazioni è molto comune, non c'è niente di sbagliato in questo. AFAIK, non è disponibile una maggiore precisione del timer. Nota: QPF potrebbe portare a problemi con macchine multiproduttore, ma l'articolo MSDN collegato prima fornisce alcune informazioni aggiuntive su questo. Si consiglia di assicurarsi che lo System.Diagnostics.Stopwatch lo faccia in background o chiamare lo SetThreadAffinity manualmente - altrimenti il ​​timer potrebbe tornare indietro nel tempo!

Si noti che per le misurazioni di altissima precisione, ci sono some subtleties che devono essere presi in considerazione. Se hai bisogno di questa precisione, questi potrebbero essere di qualche preoccupazione.

Answer 4

Esistono diverse classi di timer nella libreria di classi di base .NET: quale di queste è più adatto alle proprie esigenze può essere determinato solo dall'utente.

Here is a good article from MSDN magazine on the subject (Comparing the Timer Classes in the .NET Framework Class Library).

Answer 5

Tu dici che hai letto su un altro forum di non utilizzare le classi da System.Diagnostics in produzione. Ma l'unica fonte di cui dovresti preoccuparti è Microsoft, che ha creato il codice. Si dice che il StopWatch class:

Fornisce un insieme di metodi e proprietà che è possibile utilizzare per misurare con precisione il tempo trascorso.

Non dicono "eccetto in produzione".

Answer 6

A seconda di cosa stai usando il timer, potresti avere altri problemi da considerare. Windows non fornisce garanzie sui tempi di esecuzione, quindi non si dovrebbe fare affidamento su di esso per qualsiasi elaborazione in tempo reale (ci sono estensioni in tempo reale che si possono ottenere per Windows che forniscono una pianificazione in tempo reale).Sospetto anche che potresti perdere la precisione a causa del cambio di contesto dopo aver catturato l'intervallo di tempo e prima di fare qualcosa che dipende dalla sua precisione. In linea di principio, questo potrebbe essere un periodo di tempo arbitrariamente lungo; in pratica dovrebbe essere dell'ordine di millisecondi. Dipende davvero da quanto è critico questo momento critico.

Answer 7

Sì, System.Diagnostics suona come se fosse solo per il debug, ma non lasciare che il nome ti inganni. Lo spazio dei nomi System.Diagnostics può sembrare un po 'spaventoso per l'uso nel codice di produzione all'inizio (lo ha fatto per me), ma ci sono molte cose utili in quel namespace.

Alcune cose, come la classe Process, sono utili per l'interazione con il sistema. Con Process.Start è possibile avviare altre applicazioni, avviare un sito Web per l'utente, aprire un file o una cartella, ecc.

Altre cose, come la classe Trace, possono aiutare a rintracciare i bug nel codice di produzione. Certo, non li userete sempre nel codice di produzione, ma sono molto utili per registrare e rintracciare quel bug inafferrabile su una macchina remota.

Non preoccuparti del nome.