Présentation des outils

Choix des outils

Il existe deux façons d’aborder la question des outils :

Bien qu’il soit intéressant de disposer d’une liste afin de pouvoir comparer leurs fonctionnalités respectives, cela ne serait pas forcément intéressant dans la mesure où les outils listés ne seraient pas détaillés, obligeant ainsi à effectuer des recherches complémentaires. Ainsi, il a été choisi que ce chapitre se concentre sur la présentation des outils des profiling et de benchmarking qui seront utilisés dans les chapitres suivants, pour que le lecteur profite déjà d’une introduction à ces derniers avant de les utiliser plus en profondeur.

Le choix des outils retenus dans ce chapitre, et donc cet ouvrage, a été réalisé en fonction de l’état actuel du marché, afin que le lecteur puisse s’équiper rapidement et à moindre coût. Il faut noter que la sélection d’outils est quasi-exclusive à Windows, du fait de la maturité du framework sur ce système...

Visual Studio 2022

Visual Studio est très souvent l’outil de travail principal du développeur .NET. Il existe aujourd’hui des alternatives viables, plus ou moins avancées, comme Visual Studio Code ou Rider de JetBrains ; mais étant donné que, majoritairement, les développeurs .NET utilisent Visual Studio lorsqu’ils s’exécutent sous Windows, c’est ce dernier qui a été retenu pour l’analyse des performances.

L’avantage d’utiliser Visual Studio est qu’il propose directement l’intégration de la panoplie d’outils sans avoir à changer d’environnement tout au long des avancées dans le projet. Ainsi, on pourra effectuer une session de profiling au fur et à mesure de l’élaboration d’une fonctionnalité si cela s’avère nécessaire. De plus, c’est Microsoft lui-même qui produit Visual Studio. À cet effet, l’IDE est, de manière logique, fortement corrélé et à jour par rapport au framework .NET.

1. Fenêtre de diagnostic

Dans sa configuration par défaut, Visual Studio 2022 affiche directement les outils de diagnostic durant une session de débogage :

Fenêtre de diagnostic lors du débogage avec Visual Studio

Si cette fenêtre n’est pas visible, il suffira de l’afficher lors de l’entrée en mode Debug en allant dans le menu Déboguer, puis Fenêtres pour ensuite sélectionner Afficher les Outils de diagnostic. Le raccourci par défaut est [Ctrl][Alt][F2].

Bien que cette fenêtre donne une idée de la façon dont l’utilisation consomme des ressources et se comporte, elle n’est pas la principale source d’informations pour une session de profiling. Elle permet néanmoins de suivre certains événements majeurs ainsi que d’avoir un aperçu du pourcentage de CPU consommé et de la consommation de RAM.

On y trouvera notamment les éléments suivants :

• Les moments de passage du GC, symbolisés...

Compteurs de performance

Il est possible de suivre le comportement d’une application grâce à une longue liste de compteurs, intégrés directement au sein du système d’exploitation. C’est probablement la façon native la plus aisée pour suivre les performances à un niveau macroscopique. La surveillance par les compteurs permet effectivement de constater un éventuel problème, mais ne permettra pas de rentrer dans le détail comme le ferait Visual Studio ou d’autres outils, pour localiser la fonction ou la ligne de code incriminée.

BenchmarkdotNet

Jusqu’à présent, nous avons vu des outils permettant de suivre les performances lors d’une exécution en mode utilisateur. Cependant, comme on l’a vu dans le chapitre précédent, il est parfois judicieux d’isoler un bout de code et de le mettre sous pression dans un benchmark afin de déterminer si l’objectif de performance est atteint.

Bien sûr, il est possible de réaliser cette opération manuelle grâce à certains objets présents dans le framework, comme la classe Stopwatch, permettant de déclencher un chronomètre.

Cependant, cela impliquerait d’omettre le fonctionnement interne de C# ainsi que ses optimisations. N’oublions pas que le code C# est transformé en code IL et que ce dernier est recompilé à la volée (sauf dans le cas bien précis de la compilation AOT) par le compilateur JIT. Et c’est là que l’on peut obtenir un gain de performance ou une perte considérable.

Cette opération de compilation par le JIT se produit en effet lorsque le runtime accède au code la première fois. On appelle cela l’overhead de la compilation JIT, qui crée donc, au premier accès, un délai supplémentaire du fait de cette compilation. Néanmoins, une fois cette opération effectuée, les appels suivants sont beaucoup plus rapides, car le code a été spécifiquement compilé de façon optimale pour le processeur cible.

La problématique...