temporizador - reloj en c# con timer
¿Se puede usar Cronómetro en el código de producción? (7)
Necesito un temporizador preciso, y DateTime.Now parece no ser lo suficientemente preciso. De las descripciones que leí, System.Diagnostics.Stopwatch parece ser exactamente lo que quiero.
Pero tengo una fobia. Estoy nervioso por usar cualquier cosa de System.Diagnostics en el código de producción real. (Lo uso extensamente para depurar con Asserts e PrintLns, etc., pero nunca antes para material de producción). No estoy simplemente tratando de usar un temporizador para comparar mis funciones: mi aplicación necesita un temporizador real. He leído en otro foro que System.Diagnostics.StopWatch es solo para la evaluación comparativa, y no debe usarse en el código minorista, aunque no se proporcionó ninguna razón. ¿Es correcto, o estoy (y quien haya publicado ese consejo) siendo demasiado cerrado sobre System.Diagnostics? es decir, ¿está bien usar System.Diagnostics.Stopwatch en el código de producción? Gracias Adrian
Afaik StopWatch es un shell sobre la funcionalidad QueryPerformanceCounter . Esta función es la base de muchas mediciones relacionadas con los contadores de rendimiento. QPF es muy rápido de llamar y perfectamente seguro. Si se siente paranoico con el espacio de nombres de Diagnóstico, invoque directamente el QPF.
Debajo del capó, casi todo lo que hace Cronómetro es envolver QueryPerformanceCounter . Según tengo entendido, Stopwatch está ahí para proporcionar acceso al temporizador de alta resolución: si necesita esta resolución en el código de producción, no veo nada de malo en su uso.
Dependiendo de para qué está usando el temporizador, es posible que tenga otros problemas que considerar. Windows no proporciona garantías sobre el tiempo de ejecución, por lo que no debe confiar en él para ningún procesamiento en tiempo real (hay extensiones en tiempo real que puede obtener para Windows que proporcionan una programación duradera en tiempo real). También sospecho que puede perder precisión como resultado del cambio de contexto después de capturar el intervalo de tiempo y antes de hacer algo con eso que depende de su precisión. En principio, esto podría ser un período de tiempo arbitrariamente largo; en la práctica, debería ser del orden de milisegundos. Realmente depende de cuán crítico es este momento.
El cronómetro es básicamente una envoltura ordenada alrededor de los QueryPerformanceCounter nativos QueryPerformanceCounter y QueryPerformanceFrequency . Si no se siente cómodo utilizando el espacio de nombres System.Diagnostic , puede acceder a ellos directamente .
Usar el contador de rendimiento es muy común, no hay nada de malo en eso. AFAIK, no hay mayor precisión de temporizador disponible. Tenga en cuenta que QPF puede provocar problemas con máquinas con varios procesadores , pero el Artículo de MSDN vinculado anteriormente proporciona información adicional al respecto. Es recomendable asegurarse de que System.Diagnostics.Stopwatch haga en segundo plano o de llamar a SetThreadAffinity manualmente; de lo contrario, ¡su temporizador podría retroceder en el tiempo !
Tenga en cuenta que para mediciones de muy alta precisión, hay algunas sutilezas que deben tenerse en cuenta. Si necesita tanta precisión, estos podrían ser un motivo de preocupación.
Existen varias clases de temporizadores diferentes en la biblioteca de clases base de .NET. Solo usted puede determinar cuál se adapta mejor a sus necesidades.
Sí, System.Diagnostics suena como si fuera solo para la depuración, pero no dejes que el nombre te engañe. El espacio de nombres System.Diagnostics puede parecer un sonido un poco aterrador para usar en el código de producción al principio (lo hice por mí), pero hay muchas cosas útiles en ese espacio de nombres.
Algunas cosas, como la clase Process , son útiles para interactuar con el sistema. Con Process.Start puede iniciar otras aplicaciones, abrir un sitio web para el usuario, abrir un archivo o carpeta, etc.
Otras cosas, como la clase Trace , pueden ayudarlo a encontrar errores en el código de producción. Por supuesto, no siempre los usará en el código de producción, pero son muy útiles para iniciar sesión y rastrear ese error difícil de alcanzar en una máquina remota.
No te preocupes por el nombre.
Usted dice que ha leído en otro foro que no use clases de System.Diagnostics en producción. Pero la única fuente de la que deberías preocuparte es Microsoft, quien creó el código. Dicen que la clase StopWatch :
Proporciona un conjunto de métodos y propiedades que puede usar para medir con precisión el tiempo transcurrido.
No dicen "excepto en producción".