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
Die Profilerstellungs-API wurde in .NET Framework 2.0 um zusätzliche Funktionen erweitert. Die neue Funktionalität wird über zwei neue Schnittstellen verfügbar gemacht: ICorProfilerCallback2 und ICorProfilerInfo2.
Eine Profiler-DLL, die für .NET Framework, Version 1.0 oder 1.1, geschrieben wurde, funktioniert in der Common Language Runtime (CLR)-Umgebung von .NET Framework 2.0 nicht richtig. Um die Profiler-DLL zur Verwendung mit Version 2.0 zu aktualisieren, müssen Sie die ICorProfilerCallback2-Schnittstelle implementieren. Die ICorProfilerInfo2-Schnittstelle erbt von der ICorProfilerInfo-Schnittstelle und führt neue Methoden ein, die eine erweiterte Interaktion mit der CLR unterstützen.
Generika
Die Einführung von Generika in der Laufzeit hat drei Änderungen in der Profilerstellungs-API bewirkt:
Es gibt keine Eins-zu-Eins-Zuordnung zwischen typedef-Token und ClassID-Werten oder zwischen MethodDef-Token und FunctionID-Werten mehr. Das liegt daran, dass jede Klasse oder Funktion für verschiedene Typen instanziiert werden kann. Entwickler von Profilern sollten den Abschnitt Profilerstellungs- und Laufzeitbenachrichtigungs-IDs lesen, überprüfen, wie sie die ICorProfilerInfo::GetClassFromToken-Methode und die ICorProfilerInfo::GetFunctionFromToken-Methode in ihrem Code verwenden, und den Code generikafähig umschreiben. Die Profilerstellungs-API stellt zur Unterstützung von Generika zwei neue Methoden bereit: ICorProfilerInfo2::GetClassFromTokenAndTypeArgs und ICorProfilerInfo2::GetFunctionFromTokenAndTypeArgs.
Es gibt keine direkte Zuordnung zwischen einer FunctionID und der darin enthaltenen ClassID mehr. Optimierungen für die gemeinsame Verwendung von Code können verschiedene Instanziierungen eines generischen Typs zur Freigabe von Code ermöglichen. Sie können die ClassID einer FunctionID nur bestimmen, wenn Sie sie im Kontext einer bestimmten Aktivierung der Funktion überprüfen.
Die vorhandenen Methoden für Klassen- und Funktionsinformationen in der ICorProfilerInfo-Schnittstelle stellen keine Informationen über Typargumente für generische Typen und Funktionen bereit. Zu diesem Zweck wurden die ICorProfilerInfo2::GetClassIDInfo2-Methode und die ICorProfilerInfo2::GetFunctionInfo2-Methode bereitgestellt. Beachten Sie, dass diese Methoden die Informationen nicht immer bereitstellen können. Weitere Informationen finden Sie unter Profilerstellungs- und Laufzeitbenachrichtigungs-IDs.
Codeaufteilung
Die Assemblys in .NET Framework wurden einer Leistungsoptimierung unterzogen. Vorkompilierter systemeigener Code wurde pro Funktion in mehrere Bereiche aufgeteilt. Daher kann die vorhandene ICorProfilerInfo::GetCodeInfo-Methode den Umfang des systemeigenen Codes einer Funktion nicht mehr richtig beschreiben. Profiler sollten stattdessen die allgemeinere ICorProfilerInfo2::GetCodeInfo2-Methode verwenden.
Aufhebung des prozessinternen Debuggens
In .NET Framework 2.0 wurde das prozessinterne Debuggen durch eine Gruppe von Funktionen ersetzt, die gegenüber der Profilerstellungs-API konsistent sind. Daraus sind die Features für Stapelsnapshot und Objektüberprüfung hervorgegangen.
Rückrufe mit dem Native Image Generator
Deutliche Optimierungen im Native Image Generator (NGen.exe) haben dazu geführt, dass noch mehr Arbeit von der Laufzeit auf die Generierung von systemeigenen Abbildern verlagert wurde. Dies hat zu folgenden Änderungen im Verhalten der Profilerstellungs-API geführt:
Für die meisten Funktionen werden JITCachedFunctionSearch-Rückrufe nicht mehr in systemeigenen Abbildern empfangen. Ein Profiler hat je nach Verwendung von Rückrufen zwei Möglichkeiten:
Wenn der Profiler Rückrufe verwendet, um Informationen über eine Funktion zu sammeln, kann er zu einem Schema wechseln, bei dem Informationen über eine bestimmte Funktion nur gesammelt werden, wenn diese Funktion zuerst während der Programmausführung gefunden wird.
Wenn der Profiler Rückrufe verwendet, um zu erzwingen, dass eine Funktion zu Instrumentationszwecken Just-In-Time (JIT)-kompiliert wird, kann er stattdessen durch den Profiler verbesserte systemeigene Abbilder verwenden. Weitere Informationen finden Sie unter Codegenerierung in der Profilerstellungs-API.
Für die meisten Typen werden ClassLoad-Rückrufe nicht mehr in systemeigenen Abbildern empfangen. Profiler sollten für solche Klassen Laufzeitauswertungsverfahren (auch verzögerte Auswertung genannt) verwenden. Profiler, die bereits durch den Profiler verbesserte systemeigene Abbilder verwenden, müssen ihr Verhalten nicht ändern. Da sich durch den Profiler verbesserte systemeigene Abbilder von regulären Abbildern stark unterscheiden, sollte ein Profiler diese Abbilder nur dann verwenden, wenn er sie unbedingt benötigt.
Verbesserte Garbage Collection-Rückrufe
Die Garbage Collection-Rückrufe wurden in mehrerer Hinsicht verbessert. Rückrufe benachrichtigen den Profiler jetzt, wenn Garbage Collection-Handles erstellt oder zerstört wurden, stellen Informationen über das Einreihen von zu finalisierenden Objekten in Warteschlangen bereit und verwenden die Collect-Methode, um eine Garbage Collection zu erzwingen. Die ICorProfilerCallback2::RootReferences2-Methode, die eine Erweiterung von ICorProfilerCallback::RootReferences ist, stellt Informationen über den Typ jedes Stamms bereit. Schließlich meldet die ICorProfilerCallback2::SurvivingReferences-Methode das Layout von Objekten im Heap, das durch eine nicht komprimierende Garbage Collection verursacht wird.
Fixierte Objekte
Fixierte Objekte, eine Neuheit in .NET Framework 2.0, sind konstante Objekte, die zum Zeitpunkt der Generierung von systemeigenen Abbildern initialisiert und in das systemeigene Abbild geschrieben werden. Fixierte Objekte werden durch die Garbage Collection nicht verschoben, können aber von Garbage Collection-Objekten referenziert werden. Die neue ICorProfilerInfo2::EnumModuleFrozenObjects-Methode ermöglicht Profilern, fixierte Objekte aufzulisten.
Verschiedene API-Änderungen
In .NET Framework 2.0 wurden außerdem die folgenden API-Änderungen eingeführt:
Die ICorProfilerInfo::SetFunctionReJIT-Methode gibt jetzt E_NOIMPL zurück. In früheren Versionen führte ein Aufruf dieser Methode zu einem Deadlock.
Die neue ICorProfilerCallback2::ThreadNameChanged-Methode stellt Benachrichtigungen zu geänderten Threadnamen bereit.
Die neue ICorProfilerInfo2::GetThreadAppDomain-Methode akzeptiert eine Thread-ID und gibt die Anwendungsdomäne zurück, in der dieser Thread ausgeführt wird.
Siehe auch
Weitere Ressourcen
Profilerstellung in .NET Framework