[VS 2010 Team Dev] Quoi de neuf dans le Profiler?
Depuis Visual Studio 2005 Team Dev, le profiler de code permet de mettre en avant les goulets d’étranglement d’une application testée (quelles sont les fonctions qui prennent le plus de temps, quelles sont celles qui consomment le plus de mémoire…).
En version 2008, celui à juste reçut 2 fonctionnalités additionnelles mais fort pratique:
- Comparaison de rapport: pour savoir si les modifications sur le code ont eut un impact positif / négatif sur les performances
- Mise en avant du chemin critique: dans un rapport avec un arbre d’appel conséquent, le goulet d’étranglement est directement mis en avant
(détaillées ici)
La version 2010 voit encore son petit lot de nouveautés permettant d’améliorer encore l’expérience de l’utilisation de celui-ci, au programme de ce post:
- Modification de l’assistant de création de séance de profiling
- Profiling multi-applications
- Améliorations du rapport général
- Une nouvelle vue dans le rapport: functions détails
- Profiling de JavaScript
- Stockage des données de configuration de performance
Modification de l’assistant de création de séance de profiling
VS 2008:
VS 2010:
Modifications:
L’ordre des fenêtres a changé, on décide d’abord du type de profiling avant de choisir l’application ciblée.
Sur le type de profiling, deux nouvelles options sont apparues:
- .NET Memory Allocation (Sampling): permet de faire une séance de profiling en se concentrant non pas sur les temps d’exécution des méthodes, mais sur la consommation mémoire de chacune. Ce mode était activable avant au travers d’un menu contextuel et du paramétrage une fois l’assistant passé. L’atteindre sera maintenant plus intuitif
- Concurrency: Nouveau mode de profiling qui se concentre sur la détection des problèmes lié aux applications multithread (car le profiler gère ce type d’application de mieux en mieux depuis sa version 2008)
Sur le type des applications pouvant être profiler, aucun changement si ce n’est le remplacement d’une DropDownLost par une ListBox (a noter que cela permet du coup de sélectionner plusieurs projets à Profiler en même temps!).
Sur la derrière fenêtre, une case cochée par default permet de lancer automatiquement (cela surprend la première fois de voir l’application s’exécuter immédiatement).
Profiling multi-application
Il est possible de profiler d’un coup plusieurs tiers d’une application (en 2008, il fallait ouvrir une instance de Visual Studio pour chacun) et de faire apparaitre du coup un rapport de dépendances (combien de fois une des pages de mon application Web fait appel à un service de ma couche WCF).
Je ne peux pas détailler plus pour l’instant car cette fonctionnalité semble dysfonctionner dans la béta 1 (j’éditerai le post plus tard).
Améliorations du rapport général
VS 2008:
VS 2010:
Modifications:
Bon, la capture d’écran parle d’elle même, Visual Studio 2010 est en WPF, l’équipe qui fait le profiler en a profité pour faire quelque chose de beau.
A noter donc:
- en haut a gauche, une gestion de l’historique dans les scénarios d’analyse des rapports, qui permet donc de revenir en arrière lorsque l’on navigue de rapport en rapport en détail de rapport...
- en haut au milieu, toujours la possibilité de changer de vue d’analyse (Summary, Call Tree, Modules, Caller/Callee, Functions, Function details, Mark, Process) et quelques icones d’option (notamment une nouvelle option de split de fenêtre, grisée dans la beta)
- Au milieu gauche, la mise en avant du chemin critique, directement ici
- En bas, le détail des fonctions qui ont pris le plus de temps mais avec une vue en % et en graphe, plus simple à la lecture
- Au milieu droit, les options accessible habituellement de la barre d’outil et du menu contextuel en mode “détaillé” pour aller directement vers l’option désirée
Une nouvelle vue dans le rapport: Function Détails
Permet d’avoir une cartographie en WPF de l’utilisation d’une méthode, avec vue en même temps sur son code
Ici on remarque, que la méthode “MethodeB” (dont le code s’affiche en bas) est appelée pendant 222,0 millisecondes dans la méthode A (zone bleu de gauche) et que durant son appel, 0,8 millisecondes sont exploitées dans son code, 217,7 dans le sous appel à System.String.Concat(), 3,5 a Int32.ToString() et moins de 0,1 a Object.ToString().
Cette méthode représente également (au milieu de l’écran), 53,0% du temps d’exécution de l’application.
En mode “informations mémoire”, des instructions apparaissent directement dans le designer de code (par exemple ci-dessous, en rouge ce qui consomme le plus de mémoire avec sur la gauche la taille que cela représente).
Profiling de JavaScript
En mode instrumentation, il est maintenant possible d’activer le profiling du JavaScript trouvé dans une analyse de navigation Web.
Il suffit pour ceci d’activer l’option (désactivée par default), d’une séance de profiling Web.
Soit le code suivant:
Le profiler remonte dans son rapport le chemin d’exécution suivant:
et toujours la fenêtre de détail liée:
Stockage des données de configuration de performance
Toute petite fonctionnalité mais bien pratique, la configuration d’une session de performance est maintenant stockée au coté de la Solution, dans un répertoire Solution Items (avant c’était un fichier non lié, dépendant du Visual Studio de la personne ayant fait l’analyse de performance).
Ceci est pratique pour pour re-trouver les anciennes configuration et surtout les versionner pour diffuser aux autres membres de l’équipe via un contrôleur de code source (et leur permettre ainsi d’analyser les performance de l’application avec le même paramétrage).
Voila, bonne découverte!
(je compléterai ce post au fur et à mesure des modifications)
