.NET Chronomètre - pénalité de performance

Question

Doublons possibles:
Is DateTime.Now the best way to measure a function's performance?
Stopwatch vs. using System.DateTime.Now for timing events

J'ai le code qui doit courir aussi vite que possible. Pour pouvoir enregistrer l'heure d'exécution, j'utilise la classe Stopwatch. Je suppose que Stopwatch peut affecter la performance d'une mauvaise façon. Peut-être que l'utilisation d'une différence DateTime peut être plus efficace?

À votre avis, quelle est la meilleure performance?

Stopwatch sw = new Stopwatch(); 
sw.Start(); 
int a = 5; 

// Critical lines of code 

long elapsedMs = se.Elapsed.TotalMilliseconds; 

OU

DateTime startDate = DateTime.Now; 
int a = 5; 

// Critical lines of code 

long elapsedMs = DateTime.Now.Subtract(startDate).TotalMilleseconds; 

Answer 1

Le Stopwatch ne fait rien entre les appels à Start et Stop ... Il stocke simplement l'horodatage en cours (via QueryPerformanceCounter) lorsque vous démarrez, et le compare à l'horodatage en cours lorsque vous l'arrêtez. Il n'y a donc aucune raison pour que cela affecte les performances de votre code, du moins pas de manière significative. Stopwatch a été conçu spécifiquement pour des mesures de temps précises, de sorte que vous pouvez être sûr qu'il est complètement optimisé. Il est également beaucoup plus précis que la comparaison des valeurs successives de DateTime.Now. ...

Answer 2

Je pense que le second sera plus efficace dans la mesure où la performance est concerné, et que les liens dans le commentaire indiquent, si vous voulez mesurer le temps ci-dessous secondes puis DateTime ne sera pas précis bien qu'il serait efficace

Je pense que parce que StopWatch mesurerait les ticks continuellement comparé à DateTime qui ne contiendra qu'une seule instance de DateTime, c'est-à-dire startTime.

Answer 3

Puisque votre code de profilage n'est exécuté qu'une seule fois, son impact sur les performances devrait être négligeable. C'est seulement un problème si vous mettez des appels au chronomètre à l'intérieur de votre boucle interne/chemins de code critiques.

GetTickCount() devrait être l'un des moyens les plus rapides de profil, mais il a seulement une précision de quelques millisecondes. La fonction API Windows GetTickCount() vérifie uniquement une variable simple (qui est mise à jour toutes les quelques millisecondes); son coût est le coût d'une invocation de méthode native et rien de plus. Il est exposé comme Environment.TickCount dans .NET. Mais comme je l'ai dit, je doute que cela compte. DateTime.UtcNow/Now ont la même (faible) précision que GetTickCount.

En théorie, il pourrait y avoir un effet sur la gigue, mais c'est peu probable.

Answer 4

Je ne pense pas que ce soit vraiment important si vous ne l'appelez que quelques fois, Cependant, tout dépend de quel est le niveau de précision que vous demandez; Stopwatch est beaucoup plus précis, car il s'appuie sur QueuePerformanceCounter API, donc il utilise une résolution plus élevée.

Answer 5

La réponse dépend vraiment de la précision que vous essayez d'atteindre. Pour une précision supérieure à quelques secondes, le chronomètre est une meilleure approche grâce à l'utilisation d'un système de mesure plus précis que le chronomètre. Voir http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx

Du point de vue de la performance, je doute qu'il y ait beaucoup d'une différence de voir comment le départ() et DateTime.Now stockent les valeurs du système de mesure correspondant et lors de la récupération des millisecondes il calcule la différence et convertit (selon les besoins) en l'unité de mesure correspondante