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) :

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

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

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

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 :

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

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 :

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

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 :

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

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

Et lancer simplement l’analyse :

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

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) :

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 :

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…