web-dev-qa-db-fra.com

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

Doublons possibles:
DateTime.Now est-il le meilleur moyen de mesurer les performances d'une fonction?
Chronomètre vs utilisation de System.DateTime.Now pour les événements de chronométrage

J'ai du code qui doit s'exécuter le plus rapidement possible. Pour pouvoir enregistrer le temps d'exécution, j'utilise la classe Chronomètre . Je soupçonne que le chronomètre peut affecter les performances de manière négative. Peut-être que l'utilisation d'une différence DateTime peut être plus efficace?

Lequel pensez-vous a de meilleures performances?

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

// Critical lines of code

long elapsedMs = se.Elapsed.TotalMilliseconds;

OR

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

// Critical lines of code

long elapsedMs = DateTime.Now.Subtract(startDate).TotalMilleseconds;
c#.netstopwatch
46
Ahmet Altun

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

68
Thomas Levesque

Étant donné que votre code de profilage n'est exécuté qu'une seule fois, son impact sur les performances doit être négligeable. Ce n'est un problème que si vous placez des appels au chronomètre dans votre boucle interne/chemins de code critiques.

GetTickCount() devrait être l'un des moyens les plus rapides de profiler, mais il n'a qu'une précision de quelques millisecondes. La fonction GetTickCount() Windows API ne vérifie qu'une simple variable (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 in . NET . Mais comme je l'ai dit, je doute que ce soit important. DateTime.UtcNow/Now ont la même (faible) précision que GetTickCount.

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

9
CodesInChaos

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 en raison de l'utilisation d'un système de mesure plus précis que le datetime. Voir http://msdn.Microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx

Du point de vue des performances, je doute qu'il y ait beaucoup de différence en voyant comment Start () et DateTime stockent maintenant les valeurs du système de mesure correspondant et lors de la récupération des millisecondes, il calcule la différence et convertit (au besoin) en l'unité de mesure correspondante

2
virlan2004

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, il utilise donc une résolution plus élevée.

2
Jalal Said

Je pense que le second sera plus efficace en ce qui concerne les performances, et comme les liens dans le commentaire l'indiquent, si vous voulez mesurer le temps en dessous de secondes, DateTime ne sera pas précis, bien qu'il soit efficace

Je pense que oui parce que StopWatch mesurerait les ticks en continu par rapport à DateTime qui ne contiendra qu'une seule instance de DateTime, c'est-à-dire startTime.

1
Haris Hasan