Profilage de performance sur tests dans Visual Studio 2010

Pour commencer, un petit caveat : vous ne pourrez reproduire ce qui suit que sur une version Premium ou Ultimate de Visual Studio 2010.

Je souhaitais rediger ce petit post pour éviter si possible à certains de mes lecteurs de galérer comme un imbécile à chercher une solution compliquée pour faire quelque chose de simple. Supposons que vous souhaitiez lancer une analyse de performance par le profileur embarqué dans Visual Studio 2010, et ce en vous basant sur des tests (pour ceux qui ne connaissent pas le profilage, je me permets de vous renvoyer à mon bouquin sur le sujet) :

image

Pour cela, on pourrait s’imaginer qu’on va instrumenter la ClassLibrary :

image

Et derrière, on se branche sur MSTest.exe pour exécuter le code de test :

image

Quand on lance, on voit le message d’erreur suivant :

image

Que je recopie ici, juste pour aider à l’indexation :

MSTest.exe est signé et son instrumentation rendra sa signature non valide. Si vous poursuivez sans événement de post-instrumentation pour signer à nouveau le binaire, il risque de ne pas être chargé correctement. Voulez-vous continuer sans le resigner ?

Que se passe-t-il ? Simplement que, comme on est en mode instrumentation, Visual Studio a besoin de modifier les assemblages pour pouvoir profiler dessus. Or, nous n’avons pas indiqué que l’exécutable, en l’occurrence le lanceur de tests de Visual Studio, ne devait pas être lui-même instrumenté. Qu’à cela ne tienne, on va simplement décocher ceci dans l’Explorateur de performances :

image

Tout a l’air de bien se passer. On voit le test se lancer :

image

Le rapport est bien créé, également.

Mais cela ne fonctionne toujours pas, dans le sens où le rapport de performance est vide, et même refuse de s’ouvrir. On voit bien Visual Studio tenter de l’ouvrir, mais il se referme immédiatement et automatiquement, sans message d’erreur.

Arrivés à ce point, vous vous dites qu’il faut peut-être pointer de manière plus explicite sur les librairies instrumentées, en les plaçant dans un répertoire à part, vu qu’une option sur les propriétés de Performance vous permet de le faire :

image

Mais non, rien n’y fait… Bref, après une demie-heure à essayer de faire le malin, il faut bien se rendre à l’évidence : il va falloir lire la doc Sourire

Et évidemment, il y a un moyen d’une simplicité phénoménale d’arriver au bon résultat, à savoir simplement générer une session de profilage depuis la fenêtre Affichage des tests. Vous pouvez activer celle-ci depuis le menu Test, comme ceci :

image

Dans la fenêtre qui apparait, il ne reste plus qu’à lancer une session de performance sur le test unitaire…

image

Vous pouvez alors simplement choisir la méthode de profilage (la première page de l’assistant ne contient qu’une information) :

image

Et lancer simplement l’analyse :

image

Au final, vous obtenez les résultats tant attendus :

image

Dans notre cas, il s’agissait simplement de démontrer la supériorité en termes de performance d’un AddRange sur un Add en boucle sur une liste générique (sur 1000 appels d’une liste de 100 chaînes, on passe de 30,80 ms à seulement 0,87 ms).

J’en profite d’ailleurs pour rajouter une remarque rapide sur un problème tout bête : lorsqu’on profile sur des cas de benchmarks, et non pas sur des situations plus réalistes, il arrive qu’on ne voit pas les entrées dans le rapport de profilage pour certaines des fonctions qui sont appelées.

Le réflexe est d’aller voir si on a bien désactivé le filtre de suppression des fonctions les plus courtes (en termes de temps) :

image

Mais même en supprimant ceci, il arrive qu’on ne voit pas les fonctions recherchées car elles sont trop courtes en termes de taille. En effet, dans les propriétés de l’analyse de performance, une option Exclure les petites fonctions de l’instrumentation est par défaut activée :

image

Attention, lorsque vous aurez désactivé cette option, il faut bien penser à relancer l’analyse : nous ne sommes pas sur un filtre du rapport après coup, mais bien une option de l’enregistrement…

About JP Gouigoux

Jean-Philippe Gouigoux est Architecte Logiciel, MVP Connected Systems Developer. Il intervient régulièrement à l'Université de Bretagne Sud ainsi qu'à l'Agile Tour. Plus de détails sur la page "Curriculum Vitae" de ce blog.
This entry was posted in .NET, Tests and tagged . Bookmark the permalink.

One Response to Profilage de performance sur tests dans Visual Studio 2010

  1. dotnet says:

    J’ai vraiment eu de la chance en trouvant cet article. J’ai effectivement été bloqué par ce profileur de Visual Studio 2010, mais là, tout est devenu plus clair. Il est vrai que DotNET offre des composants plus faciles d’utilisation, pourtant on peut toujours rencontrer quelques problèmes en cours de route, c’est tout l’intérêt de vos articles.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha Captcha Reload