Verzögerungen und die Gesamtleistungsfähigkeit stehen in direktem Zusammenhang mit dem Ausführungsmodus einer Blazor-WebAssembly-Anwendung. Im Debug-Modus kann jede Änderung von Komponenteneigenschaften oder gebundenen Parametern dazu führen, dass die Benutzeroberfläche für 20-30 Sekunden oder sogar länger einfriert – abhängig von der Komplexität der Seite.
Wie wird das Problem reproduziert?
Wenn die Anwendung über Visual Studio gestartet wird (dotnet build / dotnet run), können lange Verzögerungen konsistent reproduziert werden. Nach der Veröffentlichung der Anwendung ändert sich die Situation jedoch dramatisch:- dotnet publish wird ausgeführt;
- die Anwendung wird von der Befehlszeile aus gestartet;
- die Verzögerungen verschwinden fast vollständig.
Dies ist ein wichtiger Punkt bei der Diagnose von Leistungsproblemen in Blazor WebAssembly-Anwendungen.
Warum passiert das?
Der Debug-Modus läuft erheblich langsamer, wenn dotnet build / dotnet run verwendet werden:- C# wird in IL (Intermediate Language) kompiliert;
- der Browser lädt die IL-Assemblys herunter;
- der Code wird über die .NET-Laufzeitumgebung ausgeführt, die in WebAssembly läuft.
In der Debug-Konfiguration sind viele Optimierungen deaktiviert, sodass rechenintensive Vorgänge deutlich langsamer ausgeführt werden. Dies macht sich besonders bei der Verwendung der SixLabors.ImageSharp-Bibliothek bemerkbar, die stark auf Bildverarbeitung und -transformationen angewiesen ist.
Was ändert dotnet publish?
Durch die Veröffentlichung werden die Release-Optimierungen aktiviert:- nicht verwendeter Code wird entfernt (Trimming);
- die Anwendungsgröße wird reduziert;
- Laufzeitoptimierungen werden aktiviert;
- der Ausführungs-Overhead wird reduziert.
Selbst das allein kann die Leistung um ein Vielfaches verbessern. Wichtig!
AOT wird nicht automatisch aktiviert! Es gibt ein weit verbreitetes Missverständnis, dass dotnet publish automatisch die AOT-Kompilierung aktiviert. In Wirklichkeit muss vollständiges Native AOT explizit über eine spezielle Projekteinstellung aktiviert werden:
<RunAOTCompilation>true</RunAOTCompilation>
Schlussfolgerung
Der Unterschied zwischen Debug- und Veröffentlichungsmodus in Blazor WebAssembly kann enorm sein. Bevor Sie Leistungsprobleme analysieren, ist es wichtig zu überprüfen:- ob ein Release-Build verwendet wird;
- ob AOT aktiviert ist;
- ob sich das Problem nach dotnet publish immer noch reproduziert.
In vielen Fällen läuft die veröffentlichte Version der Anwendung um ein Vielfaches schneller und beseitigt vollständig die kritischen Verzögerungen der Benutzeroberfläche, die beim Debuggen der Anwendung auftreten.