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.
.NET-Anwendungsstartzeit und Latenz können verbessert werden, indem Sie Ihre Anwendungsassemblys als ReadyToRun (R2R)-Format kompilieren. R2R ist eine Form der AOT-Kompilierung (Ahead-Of-Time).
R2R-Binärdateien verbessern die Startleistung, indem sie den Arbeitsaufwand des JIT-Compilers (Just-in-time) reduzieren, der anfällt, wenn Ihre Anwendung geladen wird. Die Binärdateien enthalten ähnlichen nativen Code im Vergleich zu dem, was der JIT-Compiler produzieren würde. R2R-Binärdateien sind jedoch größer, da sie sowohl IL-Code (Intermediate Language, Zwischensprache), der für einige Szenarios noch benötigt wird, als auch die native Version des gleichen Codes enthalten. R2R ist nur verfügbar, wenn Sie eine App veröffentlichen, die auf bestimmte Laufzeitumgebungen (RID) wie Linux x64 oder Windows x64 ausgerichtet ist.
Um Ihr Projekt als ReadyToRun zu kompilieren, muss die Anwendung mit der PublishReadyToRun-Eigenschaft veröffentlicht werden, auf die true
sie festgelegt ist.
Es gibt zwei Möglichkeiten, Ihre App als ReadyToRun zu veröffentlichen:
Geben Sie das PublishReadyToRun-Flag direkt an den Dotnet-Veröffentlichungsbefehl an. Details finden Sie unter dotnet publish .
dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true
Geben Sie die Eigenschaft im Projekt an.
- Fügen Sie dem Projekt die
<PublishReadyToRun>
Einstellung hinzu.
<PropertyGroup> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup>
- Veröffentlichen Sie die Anwendung ohne spezielle Parameter.
dotnet publish -c Release -r win-x64
- Fügen Sie dem Projekt die
Auswirkungen der Verwendung des ReadyToRun-Features
Die Vorabkompilierung hat komplexe Auswirkungen auf die Leistung der Anwendung, was schwer vorhergesagt werden kann. Im Allgemeinen wird die Größe einer Assembly auf zwei bis dreimal größer wachsen. Diese Erhöhung der physischen Größe der Datei kann die Leistung des Ladens der Assembly vom Datenträger verringern und den Arbeitssatz des Prozesses erhöhen. Im Gegenzug wird die Anzahl der zur Laufzeit kompilierten Methoden jedoch in der Regel erheblich reduziert. Das Ergebnis ist, dass die meisten Anwendungen mit großen Codemengen große Leistungsvorteile von der Aktivierung von ReadyToRun erhalten. Anwendungen mit kleinen Codemengen haben wahrscheinlich keine erhebliche Verbesserung durch die Aktivierung von ReadyToRun, da die .NET-Laufzeitbibliotheken bereits mit ReadyToRun vorkompiliert wurden.
Die hier erläuterte Startverbesserung gilt nicht nur für den Anwendungsstart, sondern auch für die erste Verwendung von Code in der Anwendung. Beispielsweise kann ReadyToRun verwendet werden, um die Antwortlatenz der ersten Verwendung der Web-API in einer ASP.NET-Anwendung zu reduzieren.
Interaktion mit gestufter Kompilierung
Vor der Zeit generierter Code ist nicht so hoch optimiert wie code, der vom JIT erstellt wird. Um dieses Problem zu beheben, ersetzt die mehrstufige Kompilierung häufig verwendete ReadyToRun-Methoden durch JIT-generierte Methoden.
Wie wird der Satz von vorkompilierten Assemblys ausgewählt?
Das SDK kompiliert die Assemblys, die mit der Anwendung verteilt werden. Bei eigenständigen Anwendungen enthält dieser Satz von Assemblys das Framework. C++/CLI-Binärdateien sind nicht für die ReadyToRun-Kompilierung berechtigt.
Verwenden Sie die Liste, um bestimmte Assemblys aus der <PublishReadyToRunExclude>
ReadyToRun-Verarbeitung auszuschließen.
<ItemGroup>
<PublishReadyToRunExclude Include="Contoso.Example.dll" />
</ItemGroup>
Wie wird der Satz von Methoden vorkompiliert?
Der Compiler versucht, so viele Methoden wie möglich vorab zu kompilieren. Aus verschiedenen Gründen wird jedoch nicht erwartet, dass die Verwendung des ReadyToRun-Features die Ausführung des JIT verhindert. Solche Gründe können umfassen, sind jedoch nicht beschränkt auf:
- Verwenden von generischen Typen, die in separaten Assemblys definiert sind.
- Interoperabilität mit systemeigenem Code.
- Die Verwendung von systeminternen Hardwarekomponenten, die der Compiler nicht nachweisen kann, ist sicher, dass er auf einem Zielcomputer verwendet werden kann.
- Bestimmte ungewöhnliche IL-Muster.
- Dynamische Methodenerstellung über Spiegelung oder LINQ.
Symbolgenerierung für die Verwendung mit Profilern
Beim Kompilieren einer Anwendung mit ReadyToRun benötigen Profiler möglicherweise Symbole zum Untersuchen der generierten ReadyToRun-Dateien. Um die Symbolgenerierung zu aktivieren, geben Sie die <PublishReadyToRunEmitSymbols>
Eigenschaft an.
<PropertyGroup>
<PublishReadyToRunEmitSymbols>true</PublishReadyToRunEmitSymbols>
</PropertyGroup>
Diese Symbole werden im Veröffentlichungsverzeichnis platziert, und für Windows wird die Dateierweiterung "ni.pdb" verwendet, und für Linux wird die Dateierweiterung ".r2rmap" verwendet. Diese Dateien werden in der Regel nicht an Endbenutzer weiterverteilt, sondern in der Regel auf einem Symbolserver gespeichert. Im Allgemeinen sind diese Symbole nützlich für das Debuggen von Leistungsproblemen im Zusammenhang mit dem Starten von Anwendungen, da die gestaffelte Kompilierung den generierten ReadyToRun-Code durch dynamisch generierten Code ersetzt. Wenn Sie jedoch versuchen, eine Anwendung zu profilieren, die die gestaffelte Kompilierung deaktiviert, ist dies hilfreich.
Composite ReadyToRun
Die normale ReadyToRun-Kompilierung erzeugt Binärdateien, die einzeln gewartet und bearbeitet werden können. Ab .NET 6 wurde Unterstützung für zusammengesetzte ReadyToRun-Kompilierung hinzugefügt. Composite ReadyToRun kompiliert eine Gruppe von Assemblys, die zusammen verteilt werden müssen. Dies hat den Vorteil, dass der Compiler in der Lage ist, bessere Optimierungen durchzuführen und den Satz von Methoden zu reduzieren, die nicht über den ReadyToRun-Prozess kompiliert werden können. Als Kompromiss wird die Kompilierungsgeschwindigkeit jedoch deutlich verringert, und die Gesamtdateigröße der Anwendung wird deutlich erhöht. Aufgrund dieser Kompromisse wird die Verwendung von Composite ReadyToRun nur für Anwendungen empfohlen, die die auf Linux ausgeführte Tiered Compilation oder Anwendungen deaktivieren, die die beste Startzeit mit eigenständiger Bereitstellung suchen. Um die zusammengesetzte ReadyToRun-Kompilierung zu aktivieren, geben Sie die <PublishReadyToRunComposite>
Eigenschaft an.
<PropertyGroup>
<PublishReadyToRunComposite>true</PublishReadyToRunComposite>
</PropertyGroup>
Hinweis
In .NET 6 wird Composite ReadyToRun nur für eigenständige Bereitstellungen unterstützt.
Plattformübergreifende bzw. architekturbezogene Einschränkungen
Für einige SDK-Plattformen kann der ReadyToRun-Compiler für andere Zielplattformen kompiliert werden.
Unterstützte Kompilierungsziele werden in der nachstehenden Tabelle beschrieben, wenn sie auf .NET 6 und höhere Versionen ausgerichtet sind.
SDK-Plattform | Unterstützte Plattformen |
---|---|
Windows X64 | Windows (X86, X64, Arm64), Linux (X64, Arm32, Arm64), macOS (X64, Arm64) |
Windows X86 | Windows (X86), Linux (Arm32) |
Linux X64 | Linux (X64, Arm32, Arm64), macOS (X64, Arm64) |
Linux Arm32 | Linux Arm32 |
Linux ARM64 | Linux (X64, Arm32, Arm64), macOS (X64, Arm64) |
macOS X64 | Linux (X64, Arm32, Arm64), macOS (X64, Arm64) |
macOS Arm64 | Linux (X64, Arm32, Arm64), macOS (X64, Arm64) |
Unterstützte Kompilierungsziele werden in der folgenden Tabelle beschrieben, wenn sie auf .NET 5 und unten ausgerichtet sind.
SDK-Plattform | Unterstützte Plattformen |
---|---|
Windows X64 | Windows X86, Windows X64, Windows Arm64 |
Windows X86 | Windows X86, Windows Arm32 |
Linux X64 | Linux X86, Linux X64, Linux Arm32, Linux Arm64 |
Linux Arm32 | Linux Arm32 |
Linux ARM64 | Linux ARM64 |
macOS X64 | macOS X64 |