Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Aktualisiert: November 2007
Ein Profiler ist ein Tool, das die Ausführung einer anderen Anwendung überwacht. Ein Common Language Runtime (CLR)-Profiler ist eine Dynamic Link Library (DLL), die aus Funktionen besteht, die mithilfe der Profilerstellungs-API Meldungen von der CLR empfangen und an diese senden. Die Profiler-DLL wird zur Laufzeit von der CLR geladen.
Herkömmliche Profilerstellungstools dienen vorwiegend dazu, die Ausführung der Anwendung zu messen. Das bedeutet, dass sie die für jede Funktion aufgebrachte Zeit und die Speicherauslastung der Anwendung über einen bestimmten Zeitraum messen. Die Profilerstellungs-API zielt auf eine breitere Klasse von Diagnosetools ab, z. B. Dienstprogramme zur Codeabdeckung und sogar erweiterte Debughilfen. Diese Verwendungsmöglichkeiten sind ausnahmslos von diagnostischer Natur. Die Profilerstellungs-API misst nicht nur die Ausführung einer Anwendung, sondern überwacht sie auch. Aus diesem Grund sollte die Profilerstellungs-API nie von der Anwendung selbst verwendet werden, und die Ausführung der Anwendung sollte nicht vom Profiler abhängen (oder davon beeinflusst werden).
Die Profilerstellung für eine CLR-Anwendung erfordert eine weiter reichende Unterstützung als die Profilerstellung für Computercode, der auf herkömmliche Weise kompiliert wurde. Dies liegt darin begründet, dass von der CLR Konzepte wie Anwendungsdomänen, Garbage Collection, verwaltete Ausnahmenbehandlung, Just-In-Time (JIT)-Kompilierung von Code (die Konvertierung von Microsoft Intermediate Language- bzw. MSIL-Code in systemeigenen Computercode) und ähnliche Features eingeführt werden. Herkömmliche Profilerstellungsmechanismen können keine nützlichen Informationen über diese Features identifizieren oder bereitstellen. Die Profilerstellungs-API liefert diese fehlenden Informationen hingegen in effizienter Weise und mit minimalen Auswirkungen auf die Leistung der CLR und die Anwendung, für die das Profil erstellt wird.
Die JIT-Kompilierung zur Laufzeit bietet hervorragende Möglichkeiten zur Profilerstellung. Die Profilerstellungs-API ermöglicht einem Profiler, den speicherinternen MSIL-Codestream für eine Routine zu ändern, bevor er JIT-kompiliert wird. Auf diese Weise kann der Profiler bestimmten Routinen, die genauer überprüft werden müssen, Instrumentationscode dynamisch hinzufügen. Dieser Ansatz ist zwar auch in herkömmlichen Szenarios möglich, lässt sich aber für die CLR mit der Profilerstellungs-API wesentlich einfacher umsetzen.
Die Profilerstellungs-API
Normalerweise wird die Profilerstellungs-API verwendet, um einen Codeprofiler zu schreiben. Hierbei handelt es sich um ein Programm, mit dem die Ausführung einer verwalteten Anwendung überwacht wird.
Die Profilerstellungs-API wird von einer Profiler-DLL verwendet, die in den gleichen Prozess geladen wird wie die Anwendung, für die ein Profil erstellt wird. Die Profiler-DLL implementiert eine Rückrufschnittstelle (ICorProfilerCallback in .NET Framework 1.0 und 1.1, ICorProfilerCallback2 in .NET Framework 2.0). Die CLR ruft die Methoden in dieser Schnittstelle auf, um den Profiler zu benachrichtigen, wenn Ereignisse in dem Prozess auftreten, für den ein Profil erstellt wird. Der Profiler kann mit den Methoden in der ICorProfilerInfo-Schnittstelle und in der ICorProfilerInfo2-Schnittstelle einen Rückruf in die Laufzeit durchführen, um Informationen über den Zustand der Anwendung abzurufen, für die ein Profil erstellt wird.
Tipp
Lediglich der zur Datenerfassung verwendete Teil der Profilerlösung sollte im gleichen Prozess ausgeführt werden wie die Anwendung, für die ein Profil erstellt wird. Alle Benutzeroberflächen- und Datenanalysevorgänge sollten in einem separaten Prozess ausgeführt werden.
Die folgende Abbildung zeigt, wie die Profiler-DLL mit der Anwendung, für die ein Profil erstellt wird, und der CLR interagiert.
Profilerstellungsarchitektur
.png "Profilarchitektur")
Die Benachrichtigungsschnittstellen
ICorProfilerCallback und ICorProfilerCallback2 können als Benachrichtigungsschnittstellen betrachtet werden. Diese Schnittstellen bestehen aus Methoden wie ClassLoadStarted, ClassLoadFinished und JITCompilationStarted. Jedes Mal, wenn die CLR eine Klasse lädt oder entlädt, eine Funktion kompiliert usw., ruft sie die entsprechende Methode in der ICorProfilerCallback-Schnittstelle oder in der ICorProfilerCallback2-Schnittstelle des Profilers auf.
Beispielsweise könnte ein Profiler die Codeleistung anhand von zwei Benachrichtigungsfunktionen messen: FunctionEnter2 und FunctionLeave2. Dazu versieht er lediglich jede Benachrichtigung mit einem Zeitstempel, sammelt Ergebnisse und gibt eine Liste aus, aus der ersichtlich ist, welche Funktionen während der Anwendungsausführung die meiste CPU- oder Realzeit in Anspruch genommen haben.
Die Datenabrufschnittstellen
Die anderen bei der Profilerstellung vorwiegend verwendeten Schnittstellen sind ICorProfilerInfo und ICorProfilerInfo2. Der Profiler ruft diese Schnittstellen nach Bedarf auf, um weitere Daten für seine Analysen abzurufen. Wenn die CLR beispielsweise die FunctionEnter2-Funktion aufruft, stellt sie einen Funktionsbezeichner bereit. Der Profiler kann weitere Daten über diese Funktion abrufen, indem er die ICorProfilerInfo2::GetFunctionInfo2-Methode aufruft, um die übergeordnete Klasse der Funktion, ihren Namen usw. zu erhalten.