Meilleur moyen de mesurer la vitesse des fonctions, des classes et des processus

Question

Quelle est la meilleure façon de mesurer la vitesse des fonctions et des classes?Pour chaque fonction, il existe différentes solutions et j'aimerais savoir comment mesurer la vitesse de course et optimiser mes cours partagés avec la meilleure solution possible.

Comment mesurez-vous également la vitesse SQL, par exemple les différences entre les procédures stockées, les sélections, les vues, etc.?

Answer 1

Vous avez deux options.

Utilisez System.Diagnostics.Stopwatch pour des méthodes spécifiques.

Il s'agit d'un minuteur haute résolution en .NET que vous pouvez utiliser pour des parties spécifiques de votre code.

Utilisez un profileur si vous avez besoin de mesurer les performances de l'ensemble de votre application.

Vous pouvez utiliser le profileur intégré de l'édition Ultra de Visual Studio ou un outil tel que EQATEC .

Answer 2

Il vaut mieux utiliser un profileur.Le problème avec la mesure du temps d'exécution de l'horloge murale (comme cela est fait par la classe Stopwatch) est qu'elle est influencée par de nombreux facteurs hors de votre contrôle.Pour ne citer que quelques-uns de ces facteurs, il y a la latence du réseau et d'autres E / S, et les décisions du planificateur du système d'exploitation qui influencent la priorité relative des applications et des threads.Si vous exécutez dans un environnement virtualisé, cela peut également avoir un effet relativement important sur les mesures de temps de l'horloge murale en millisecondes.Le profileur ne sera pas parfait, mais il vous donnera une meilleure idée du temps réellement passé à exécuter votre code.

En plus de cela, un bon profileur peut souvent vous donner d'autres mesures utiles, comme la quantité de mémoire utilisée par votre code pendant l'exécution.

Answer 3

Il vaut mieux ne pas confondre les objectifs de mesure et d’optimisation. Ce sont des tâches différentes. Mesurer, bien que bon pour quantifier les résultats de la correction de quelque chose, ne vous dit pas quoi réparer.

En ce qui concerne la mesure, si je veux faire une présentation de la vitesse de quelque chose, je veux un environnement contrôlé et un bon chronomètre. Cependant, à des fins d'optimisation, des mesures brutes (comme exécuter quelque chose 1000 fois) et l'utilisation d'un simple chronomètre sont plus que suffisantes.

En ce qui concerne l'optimisation, je ne suis pas préoccupé par la vitesse. Je suis préoccupé par une activité inutile. Il n'est pas nécessaire d'exécuter le code à grande vitesse pour le trouver.

Lorsqu'un programme s'exécute, il trace une arborescence d'appels. L'optimisation consiste à retirer autant de feuilles (instructions) et autant de fruits (E / S) que possible. Une bonne façon de faire est de tailler des branches entières.

• Dans tous les programmes, à l'exception des plus petits, les opportunités typiques d'optimisation consistent en des points d'appel (lignes de code où les fonctions sont appelées, pas les fonctions elles-mêmes) qui, lorsque l'on se rend compte de la quantité d'arborescence d'appels qui en résulte, pourrait vraiment être fait d'une autre manière. Une seule ligne de code d'apparence innocente pourrait être responsable d'une grande partie de l'arbre entier, et vous pourrez peut-être simplement la couper.

Pour les trouver, je pense que l'échantillonnage de la pile de temps d'horloge murale est le meilleur moyen. Il n'est pas nécessaire que ce soit un processus efficace, et un assez petit nombre d'échantillons fonctionne aussi bien (ou mieux) qu'un grand nombre d'échantillons. Il est nécessaire de le faire à plusieurs reprises, car un programme donné, tel qu'il a été écrit pour la première fois, ne contient pas qu'une seule opportunité d'accélération. Il en contient plusieurs. Voici un exemple.