À propos de l'API de profilage
Mise à jour : novembre 2007
Un profileur est un outil qui surveille l'exécution d'une autre application. Un profileur CLR (Common Language Runtime) est une bibliothèque de liaisons dynamiques (DLL) qui se compose des fonctions qui reçoivent des messages du CLR et envoient des messages à celui-ci en utilisant l'API de profilage. La DLL de profileur est chargée par le CLR au moment de l'exécution.
Les outils de profilage traditionnels se contentent de mesurer l'exécution de l'application. Autrement dit, ils mesurent le temps consacré à chaque fonction ou l'utilisation de la mémoire de l'application à la longue. L'API de profilage cible une classe plus générale d'outils de diagnostics tels que les utilitaires de couverture du code et même des outils d'aide au débogage avancés. Ces utilisations relèvent du diagnostic par nature. L'API de profilage non seulement mesure mais surveille également l'exécution d'une application. Pour cette raison, l'API de profilage ne doit jamais être utilisée par l'application elle-même, et l'exécution de l'application ne doit pas dépendre du profileur (ni être affecté par celui-ci).
Le profilage d'une application CLR requiert plus d'assistance que le profilage de code machine compilé de façon classique. Cela tient au fait que le CLR introduit des concepts tels que les domaines d'application, le garbage collection, la gestion des exceptions managées, la compilation juste-à-temps (JIT) de code (la conversion de code MSIL en code machine natif), et autres fonctionnalités similaires. Les mécanismes de profilage classiques ne peuvent pas identifier ou fournir des informations utiles à propos de ces fonctionnalités. L'API de profilage fournit efficacement ces informations manquantes, avec un effet minime sur les performances du CLR et l'application profilée.
La compilation JIT au moment de l'exécution fournit de bonnes possibilités pour le profilage. L'API de profilage permet à un profileur de modifier le flux du code MSIL en mémoire pour une routine avant sa compilation par JIT. De cette manière, le profileur peut ajouter dynamiquement le code d'instrumentation à des routines particulières qui demandent un examen plus approfondi. Bien que cette approche soit possible dans les scénarios classiques, il est beaucoup plus facile à implémenter pour le CLR en utilisant l'API de profilage.
L'API de profilage
En général, l'API de profilage est utilisée pour écrire un profileur de code, qui est un programme qui surveille l'exécution d'une application managée.
L'API de profilage est utilisée par une DLL de profileur qui est chargée dans le même processus que l'application qui est profilée. La DLL de profileur implémente une interface de rappel (ICorProfilerCallback dans le .NET Framework version 1.0 et 1.1, ICorProfilerCallback2 dans la version 2.0). Le CLR appelle les méthodes dans cette interface pour notifier au profileur les événements dans le processus profilé. Le profileur peut rappeler dans le runtime en utilisant les méthodes dans les interfaces ICorProfilerInfo et ICorProfilerInfo2 afin d'obtenir des informations à propos de l'état de l'application profilée.
.gif "Remarque") Remarque : |
|---|
Seule la partie collecte de données de la solution de profileur doit s'exécuter dans le même processus que l'application profilée. L'interface utilisateur et l'analyse de données doivent être exécutées dans un processus séparé. |
L'illustration suivante montre comment la DLL de profileur interagit avec l'application qui est profilée et le CLR.
Profilage de l'architecture
.png)
Interfaces de notification
ICorProfilerCallback et ICorProfilerCallback2 peuvent être considérées comme des interfaces de notification. Ces interfaces se composent de méthodes telles que ClassLoadStarted, ClassLoadFinished et JITCompilationStarted. Chaque fois que le CLR charge ou décharge une classe, compile une fonction, et ainsi de suite, il appelle la méthode correspondante dans l'interface ICorProfilerCallback ou ICorProfilerCallback2 du profileur.
Par exemple, un profileur pourrait mesurer la performance du code via deux fonctions de notification : FunctionEnter2 et FunctionLeave2. Il horodate tout simplement chaque notification, cumule les résultats et émet en sortie une liste qui indique quelles fonctions ont consommé le plus de ressources de l'UC ou l'heure (d'après l'horloge murale) pendant l'exécution de l'application.
Interfaces de récupération d'informations
Les autres interfaces principales impliquées dans le profilage sont ICorProfilerInfo et ICorProfilerInfo2. Le profileur appelle ces interfaces selon le cas pour obtenir plus d'informations pouvant faciliter son analyse. Par exemple, toutes les fois que le CLR appelle la fonction FunctionEnter2, il fournit un identificateur de fonction. Le profileur peut obtenir plus d'informations à propos de cette fonction en appelant la méthode ICorProfilerInfo2::GetFunctionInfo2 pour découvrir la classe parente de la fonction, son nom, et ainsi de suite.