Le chronomètre peut-il être utilisé dans un code de production ?

Question

J'ai besoin d'une minuterie précise, et DateTime.Now ne semble pas assez précis. D'après les descriptions que j'ai lues, System.Diagnostics.Stopwatch semble être exactement ce que je veux.

Mais j'ai une phobie. Je suis nerveux à l'idée d'utiliser quoi que ce soit de System.Diagnostics dans un code de production réel. (Je l'utilise abondamment pour le débogage avec les Asserts et les PrintLns etc, mais jamais encore pour des trucs de production). Je n'essaie pas simplement d'utiliser un timer pour évaluer mes fonctions - mon application a besoin d'un timer réel. J'ai lu sur un autre forum que System.Diagnostics.StopWatch ne sert qu'à l'analyse comparative et ne devrait pas être utilisé dans le code de détail, mais aucune raison n'a été donnée. Est-ce correct, ou est-ce que je suis (et celui qui a posté ce conseil) trop fermé d'esprit à propos de System.Diagnostics ? c'est-à-dire, est-ce que je peux utiliser System.Diagnostics.Stopwatch dans du code de production ? Merci Adrian

Answer 1

Sous le capot, tout ce que fait Stopwatch est d'envelopper Compteur de performance des requêtes . Si je comprends bien, Stopwatch est là pour fournir un accès à la minuterie haute résolution - si vous avez besoin de cette résolution dans le code de production, je ne vois rien de mal à l'utiliser.

Answer 2

Oui, System.Diagnostics semble être réservé au débogage, mais ne vous laissez pas tromper par son nom. Le site System.Diagnostics peut sembler un peu effrayant pour une utilisation dans un code de production au début (c'était le cas pour moi), mais il y a beaucoup de choses utiles dans cet espace de nom.

Certaines choses, comme le Process sont utiles pour interagir avec le système. Avec Process.Start vous pouvez démarrer d'autres applications, lancer un site web pour l'utilisateur, ouvrir un fichier ou un dossier, etc.

D'autres choses, comme le Trace peut vous aider à repérer les bogues dans le code de production. Certes, vous ne les utiliserez pas toujours dans du code de production, mais ils sont très utile pour la journalisation et la recherche d'un bogue insaisissable sur une machine distante.

Ne vous inquiétez pas pour le nom.

Answer 3

Afaik StopWatch est un shell over Compteur de performance des requêtes fonctionnalité. Cette fonction est à la base de nombreuses mesures liées aux compteurs de performance. QPF est très rapide à appeler et parfaitement sûr. Si vous êtes paranoïaque à propos de l'espace de noms Diagnostics, invoquez directement la QPF.

Answer 4

Le chronomètre est en fait, un emballage soigné autour du natif QueryPerformanceCounter y QueryPerformanceFrequency méthodes. Si vous ne vous sentez pas à l'aise pour utiliser le System.Diagnostic vous pouvez accéder directement à ces derniers .

L'utilisation du compteur de performance est très courante, il n'y a rien de mal à cela. AFAIK, il n'y a pas de précision supérieure disponible pour les timers. Notez que le QPF peut conduire à problèmes avec le multi processeur mais l'article MSDN cité plus haut donne des informations supplémentaires à ce sujet. Il est conseillé de s'assurer que System.Diagnostics.Stopwatch le fait en arrière-plan ou pour appeler le SetThreadAffinity manuellement - sinon votre minuterie pourrait remonter dans le temps !

Notez que pour les mesures de très haute précision, il y a quelques subtilités qui doivent être prises en compte. Si vous avez besoin d'autant de précision, ces éléments peuvent vous préoccuper.

Answer 5

Il existe plusieurs classes de minuterie différentes dans la bibliothèque de classes de base .NET. Vous êtes le seul à pouvoir déterminer laquelle est la mieux adaptée à vos besoins.

Voici un bon article du magazine MSDN sur le sujet (Comparing the Timer Classes in the .NET Framework Class Library).