Freigeben über


Profilerstellung in .NET Framework 2.0

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 für die Verwendung von Version 2.0 oder höher 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.

Die Änderungen werden in den folgenden Abschnitten beschrieben:

  • Generika

  • Codeaufteilung

  • Aufhebung des prozessinternen Debuggens

  • Rückrufe mit dem Native Image Generator

  • Verbesserte Garbage Collection-Rückrufe

  • Fixierte Objekte

  • Verschiedene API-Änderungen

Neben den API-Änderungen wurde ein neues HRESULT hinzugefügt: CORPROF_E_UNSUPPORTED_CALL_SEQUENCE. Informationen zu den Szenarien, in denen dieses HRESULT zurückgegeben werden kann, finden Sie unter CORPROF_E_UNSUPPORTED_CALL_SEQUENCE HRESULT.

Generika

Die Einführung von Generika in der Laufzeit hat drei Änderungen in der Profilerstellungs-API bewirkt:

Zurück nach oben

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.

Zurück nach oben

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 Funktionen für Stapelmomentaufnahme (siehe Übersicht über die Profilerstellung) und Objektüberprüfung hervorgegangen.

Zurück nach oben

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.

Zurück nach oben

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.

Zurück nach oben

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.

Zurück nach oben

Verschiedene API-Änderungen

In .NET Framework 2.0 wurden außerdem die folgenden API-Änderungen eingeführt:

Zurück nach oben

Siehe auch

Konzepte

Übersicht über die Profilerstellung