Chronomètre vs. utilisation de System.DateTime.Now pour les événements de chronométrage

Question

Je voulais suivre les performances de mon code, j'ai donc stocké l'heure de début et de fin en utilisant la fonction System.DateTime.Now . J'ai pris la différence entre les deux comme le temps d'exécution de mon code.

J'ai cependant remarqué que la différence ne semblait pas être exacte. J'ai donc essayé d'utiliser un Stopwatch objet. Cela s'est avéré être beaucoup, beaucoup plus précis.

Quelqu'un peut-il me dire pourquoi Stopwatch serait plus précis que de calculer la différence entre une heure de début et une heure de fin en utilisant System.DateTime.Now ?

BTW, je ne parle pas d'un dixième de pourcentage. J'obtiens environ 15 à 20 % de différence.

Answer 1

Conformément à MSDN :

Le chronomètre mesure le temps écoulé en comptant les tics de la minuterie sous-jacente. Si le matériel et le système d'exploitation installés prennent en charge un compteur de performance haute résolution, la classe Stopwatch utilise ce compteur pour mesurer le temps écoulé. Sinon, la classe Stopwatch utilise la minuterie du système pour mesurer le temps écoulé. Utilisez les champs Frequency (fréquence) et IsHighResolution (haute résolution) pour déterminer la précision et la résolution de l'implémentation du chronométrage du Stopwatch.

Il utilise une résolution/précision plus élevée que DateTime.Now .

Vous pouvez également consulter ces liens connexes :

Environment.TickCount vs DateTime.Now

DateTime.Now est-il le meilleur moyen de mesurer les performances d'une fonction ?

DateTime est assez bon pour une précision à la seconde près, mais pour tout ce qui est au-delà, je recommande StopWatch .

Answer 2

Il est préférable d'utiliser la classe Chronomètre car cette méthode est beaucoup plus précise que la soustraction de valeurs DateTime :

Stopwatch s = Stopwatch.StartNew();
// Tested code here
s.Stop();
Console.WriteLine("Elapsed Time: {0} ms", s.ElapsedMilliseconds);

Malheureusement, ce simple morceau de code ne sera pas suffisant pour obtenir des mesures précises la plupart du temps, car il y a beaucoup d'activité sous le capot du système d'exploitation, qui peut voler du temps CPU et ralentir l'exécution de votre code. C'est pourquoi il est préférable d'exécuter les tests plusieurs fois, puis de retirer les temps les plus bas et les plus élevés. Pour cette puprose c'est une bonne solution d'avoir une méthode qui exécute le code testé plusieurs fois, enlève les temps les plus bas et les plus hauts et calcule le temps moyen. J'ai publié un exemple de méthode de test dans mon blog .

Answer 3

Este fonction timing performance Ce lien traite exactement de votre problème, en particulier de ce paragraphe :

Le problème est que, selon MSDN, la résolution de la fonction DateTime.Now est de 10+ millisecondes, et nous devons l'appeler deux fois ! Cela introduirait donc une variation de plus de 20 ms dans votre mesure du temps d'exécution. Comme nos appels de fonction sont souvent susceptibles d'être beaucoup plus rapides à retourner que cette fenêtre de 20 ms, ce n'est pas suffisant.

EDIT : On dirait que le deuxième DateTime.Now est appelé à un moment différent de celui où la méthode du chronomètre se termine.