Visualisation des horodatages dans une pile d'appels

Question

J'essaie d'optimiser les performances de mon application. Et je suis curieux de savoir quelles sont les méthodes qui prennent le plus de temps à traiter et il convient donc de rechercher d'éventuelles opportunités d'optimisation.

Existe-t-il des outils gratuits existants qui m’aident à visualiser la pile d’appels et combien de temps faut-il à chaque méthode? Je pense à quelque chose qui affiche la pile d'appels sous forme de graphique à barres empilées ou de treemap facile de voir que MethodA () a pris 10 secondes, car il a appelé MethodB () et Méthode (C) en 3 et 7 secondes. à compléter.

Quelque chose comme cela existe-t-il?

Answer 1

Oui, ce sont les profileurs de performances. Découvrez RedGate ANTS et DotTrace de JetBrains, pas gratuits, mais plutôt bon marché et bien meilleurs que toutes les alternatives gratuites que j'ai vues.

Answer 2

Plusieurs profileurs sont disponibles. Je n'en connais qu'un (celui inclus dans Visual Studio Team Suite), mais ce n'est pas gratuit. Je dois dire que cela a été suffisamment puissant / fiable pour que je n’aie aucune envie de passer à un autre. L'autre dont j'ai entendu parler est le profileur .NET de Red Gate (également gratuit). Tous les deux ont des fonctionnalités incluant, sans s'y limiter, ce que vous recherchez. S'il s'agit d'un développement d'applications commerciales, vérifiez-les. :)

Answer 3

Cela est mesuré soit par instrumentation, soit par échantillonnage dans un profileur.

Instrumentation

Instrumentation équivaut à peu près à réécrire tout votre code pour effectuer les opérations suivantes:

public void Foo()
{
   //Code
}

dans

public void Foo()
{
   InformTheProfilingCodeThatFooStarted();
   //Code
   InformTheProfilingCodeThatFooEnded();
}

Etant donné que le profileur sait quand tout commence et s’arrête, il peut gérer une pile de fois où cela démarre et s’arrête et fournit cette information ultérieurement. Beaucoup vous permettent de faire cela au niveau des lignes (en faisant à peu près la même chose mais en instrumentant encore plus avant chaque ligne.

Vous obtenez ainsi des informations précises à 100% sur le "graphe d'appels" de votre application, mais le coût est le suivant: éviter l'inligne des méthodes et augmenter considérablement les frais généraux associés à chaque appel de méthode.

Échantillonnage

Une autre approche est l’échantillonnage.

Au lieu d'essayer d'obtenir des graphiques d'appels précis à 100% mais avec des fois réels , cette approche fonctionne plutôt sur le principe que, si elle vérifie régulièrement ce qui se passe dans votre application cela peut vous donner une bonne idée du temps qu’il consacre à diverses fonctions sans avoir à déployer beaucoup d’efforts pour le résoudre. La plupart des profileurs d'échantillonnage savent comment "analyser" la pile d'appels quand ils interrompent le programme, afin de pouvoir donner une idée raisonnable de l'appel de quelle fonction et du temps que cela semble prendre, mais ne pourront pas vous dire si cela a été fait. (dire) 10 appels à Foo () qui a fait dix appels à Bar () ou un appel à Foo () qui faisait partie du seul appel à Bar () qui a duré si longtemps qu'il a été échantillonné 10 fois.

Les deux approches ont leurs avantages et leurs inconvénients et résolvent des problèmes différents. En général, la méthode d’échantillonnage est la meilleure, car elle est moins invasive et devrait donc donner des informations plus précises sur ce qui prend du temps , qui est souvent la première question la plus importante avant de résoudre pourquoi .

Je ne connais qu’un seul profileur d’échantillonnage gratuit pour le code .net, le profileur redistribuable gratuit, qui est lié à la version de VS 2008 Team System (mais qui peut être téléchargé séparément). La sortie qui en résulte ne peut être facilement visualisée qu'avec une édition (très coûteuse) Team System de Visual Studio.

Red Gate ANTS ne prend pas en charge l'échantillonnage (actuellement), Jet Brains (dotTrace) et MS Visual Studio Team System sont dotés de profileurs prenant en charge les deux styles. Ce que vous préférez sur une base coûts-avantages est une question d’opinion.

Answer 4

C'est la méthode que je utiliser. Si vous avez un IDE avec un bouton pause, cela ne coûte rien et fonctionne très bien.

Cela vous indique en gros le pourcentage du temps passé dans chaque routine, et plus précisément dans chaque énoncé. C'est plus important que la durée moyenne d'exécution de la routine ou de l'instruction, car elle prend en compte automatiquement le nombre d'appels. En échantillonnant l'heure de l'horloge murale, il inclut automatiquement le processeur, les entrées-sorties et d'autres types d'heures système.

Plus important encore, si vous regardez les exemples dans lesquels votre routine figure dans la pile d'appels, vous pouvez voir non seulement ce qu'elle fait, mais aussi pourquoi . La raison qui importe, c’est que ce que vous recherchez réellement, c’est du temps qui pourrait être remplacé par quelque chose de plus rapide. Sans le " pourquoi " informations, vous devez deviner ce que c'est.

BTW: Cette technique est peu connue principalement parce que les professeurs ne l'enseignent pas (même s'ils la connaissent) car ils doivent rarement travailler avec des logiciels monstrueux comme nous le faisons dans le monde réel, ils traitent donc gprof comme paradigme fondamental du profilage.

Voici un exemple d'utilisation.

P.S. Attendez-vous à ce que les pourcentages totalisent plus de 100%. La façon de penser aux pourcentages est la suivante: si une déclaration ou une routine est sur la pile X% du temps (comme estimé à partir d’un petit nombre d’échantillons), c’est à peu près combien de temps la horloge murale diminuera si la déclaration ou la routine peut être fait pour prendre beaucoup moins de temps.