Aspnetcore: AoT-Zusammenstellung

Follow-up zum Status von Mono-Wasm

Kennen Sie ein Problem, bei dem wir den Fortschritt diesbezüglich verfolgen können?

Der aktuelle Dolmetschermodus ist sehr langsam.
https://dotnetfiddle.net/JUpsRT

.NET 300 ms
WASM: 13155 ms

Ja, wir denken, dass dies eher darauf zurückzuführen ist, dass noch nichts optimiert wurde, als ein Hinweis darauf, dass wir zu diesem Zeitpunkt auf AoT umsteigen sollten, aber wir werden mehr wissen, wenn der IL-Interpreter und die AoT-Unterstützung ausgereift sind.

@danroth27 Soweit ich das beträgt der Leistungsunterschied zwischen dem Mono IL-Interpreter und der aktuellen mono.wasm-Version etwa 5-10x. Insgesamt ist mono.wasm etwa 50-80x und der IL-Interpreter etwa 10x langsamer als eine native .NET Core-Konsolenanwendung.

Insgesamt ist der Interpreter also aktuell noch nicht sehr schnell und WebAssembly bringt noch mehr Overhead dazu.

Ich würde davon ausgehen, dass AOT wahrscheinlich noch bessere Chancen hat, die Dinge zu beschleunigen, aber Sie haben Recht, dass es wahrscheinlich zu früh ist, den Interpreter auszuschließen, da die meisten Webanwendungen nicht einmal so hohe Leistungsanforderungen haben und höchstwahrscheinlich in Ordnung sein werden mit einer interpretierten Version.

Die Effizienz von AOT ist nicht nur für intensive Anwendungen von Bedeutung. Dies ist auch für mobile und andere Low-End-Plattformen von Bedeutung, insbesondere wenn Sie den Batterieverbrauch berücksichtigen.

Gibt es derzeit eine praktikable Möglichkeit, die AoT-Kompilierung für Blazor-Projekte zu aktivieren? Ich lese immer wieder Blogbeiträge, in denen behauptet wird, Blazor habe bereits einen AoT-Modus; Wenn dies wahr ist, könnte jemand bitte auf einen Artikel verweisen, in dem erklärt wird, wie man es aktiviert?

@TheFanatr die AOT-Kompilierung ist davon abhängig, dass Mono diese Funktion unterstützt. Soweit ich das beurteilen kann, war das letzte Update zu diesem Thema von @migueldeicaza im Blazor Gitter .

Miguel de Icaza (2018-06-08 19:01):
Wir arbeiten daran. Was passiert ist ist folgendes:
Der Interpreter verwendet „emscripten“, das eine ziemlich vollständige libc hat, auf die wir uns verlassen können. Und unsere AOT-Engine wurde auf reinem LLVM aufgebaut, was von uns verlangt, die vollständige libc zu schreiben. Letzteres ist der ideale Ort, da wir native Linker und sofortige llvm-Unterstützung usw. erhalten. Aber wir würden uns auf den Weg schicken, diese libc schreiben zu müssen.
Kurzfristig bewegen wir uns also dazu, den AOT-Compiler zu emscripten, um sicherzustellen, dass wir die Kompatibilität beibehalten. Der Nachteil ist jedoch, dass die Emscripten-Tools älter sind, sodass viele der besseren Teile wie der LLVM-Linker nicht verfügbar sind. Also arbeiten wir durch diese Dinge.
Im Grunde hatten wir etwas getan, aber wir mussten bei Null anfangen, um mit dem zu arbeiten, was wir haben, ohne uns dazu zu zwingen, alles selbst zu schreiben und zu emulieren. Wir hätten versuchen können, diese beiden zu vermischen, aber das ist auch eine große Anstrengung. Also denken wir, dass wir hier und da mit einigen kunstvollen Hacks vorerst Emscripten machen können.

Kurz gesagt, sie arbeiten daran, aber es gibt keine gute Möglichkeit, dies mit den aktuellen öffentlichen Builds zu tun.

Einige ziemlich große Fortschritte wurden gerade in CoreRT gemeldet !!

https://github.com/dotnet/corert/issues/4659#issuecomment -425690500

hat jemand eine idee was das blockiert? Ich bin vielleicht bereit, ein paar Billionen Arbeitsstunden zu investieren, um AOT früher als später zu sehen, jetzt, wo Clientside Blazor von den Mächten von Microsoft festgelegt wurde. AOT wird wirklich wichtig sein, wenn wir mit Blazor (exzellente) PWAs entwickeln wollen.

@honkmother AoT wird von den mono.wasm-Leuten im https://github.com/mono/mono-Repo bearbeitet. Ich bin sicher, sie würden sich über Ihre Hilfe freuen! Dieses Problem verfolgt den Verbrauch ihrer Arbeit, sobald sie fertig ist.

Ich glaube, ich habe eine etwas verwandte Frage, aber sie ist nicht gut durchdacht und schlecht formuliert. Ich habe mit ILRepack und Blazor experimentiert und es geschafft, die meisten DLLs in einem einzigen monolithischen Blob zusammenzufassen. Beabsichtigen Sie, die gemeinsamen Bibliotheken zu irgendeinem Zeitpunkt als eine einzige DLL zusammenzufassen?

@honkmother Wir haben derzeit keine konkreten Pläne dafür, aber wir würden gerne die Ergebnisse Ihrer Experimente hören.

Ich konnte die meisten von ihnen zusammenführen, indem ich einfach ILRepack in der /dist/bin/-Ausgabe verwendet und System.Core.dll einbezieht. Die Startzeiten wurden nach dem Kombinieren der meisten Bibliotheken verbessert, aber es wurden viele kopfkratzende Fehler eingeführt, von denen ich keine Ahnung habe, wie ich sie lösen soll; und natürlich verlieren Sie die Möglichkeit, sich auf das Caching für aktualisierte Codeteile verlassen zu können, ohne den gesamten Blob erneut herunterladen zu müssen.

Gab es diesbezüglich irgendwelche Entwicklungen oder zumindest eine ETA? Serverseitig funktioniert recht gut, aber die clientseitige WASM-Leistung durch den Interpreter ist immer noch inakzeptabel, sobald das DOM einigermaßen komplex wird.

Ich glaube nicht, das AOT auf dem Mono-Repo scheint immer noch ein WIP zu sein; Ich habe gehört, dass wir es bis zum ersten Quartal 2020 haben werden, aber ich weiß nicht, ob das sicher ist. Das ist traurig, weil ich eine sehr nette PWA mit Client-Seite eingerichtet habe, aber es gibt einige Leistungsprobleme, die AOT wahrscheinlich lindern würde, ohne schmutzige Hacks zu benötigen.

In der Zwischenzeit gibt es einige Dinge, die Sie tun können, um den Schmerz zu lindern, nämlich die Verwendung von virtuellem DOM und/oder die direkte Verwendung von RenderTreeBuilder, damit Sie nicht alles auf einmal rendern und eine gewisse Kontrolle über das Geschehen haben.

Nun, ich habe mich auch gefragt, ob sich angesichts der Ankündigung vor einigen Monaten zu .NET 5 etwas geändert hat. Interessantes Zitat dort:

Das Blazor-Projekt verwendet bereits das Mono AOT. Es wird eines der ersten Projekte sein, das auf .NET 5 umstellt. Wir verwenden es als eines der Szenarien, um diesen Plan zu beweisen.

Wissen sie etwas, was wir nicht wissen?

In der Zwischenzeit gibt es einige Dinge, die Sie tun können, um den Schmerz zu lindern, nämlich die Verwendung von virtuellem DOM und/oder die direkte Verwendung von RenderTreeBuilder, damit Sie nicht alles auf einmal rendern und eine gewisse Kontrolle über das Geschehen haben.

In der Tat. Ich erstelle ein MVVM-Framework von Grund auf, inspiriert von WPF, und eines der ersten Dinge, die ich tue, ist ShouldRender zu überschreiben, um die automatischen Render-Trigger von Blazor zu deaktivieren und mich stattdessen auf Eigenschaftsänderungen zu verlassen, um Komponenten mitzuteilen, wann sie neu rendern sollen. Tatsächlich kommt eine Leistungsverbesserung von HUUUUGGGE durch die Aktualisierung von Stilen über JS-Interop statt StateHasChanged , wann immer dies möglich ist.

Trotzdem habe ich Probleme, wenn große DOMs im Voraus generiert werden müssen - zum Beispiel eine komplexe Liste oder ein Datengrid. Die Serverseite ist in Ordnung, aber die Clientseite dauert manchmal 5-10 Sekunden, nur um das anfängliche Rendern durchzuführen.

Was wir wirklich brauchen, ist ein VirtualizingPanel wie in WPF. Ich habe lange darüber nachgedacht, wie dies in Blazor- und JS-Interop implementiert werden könnte, aber eine vollständige Lösung entzieht sich mir immer noch. In WPF funktioniert es, weil das Framework dafür verantwortlich ist, jedes visuelle Element zu messen und seine Größe zu melden. Selbst mit JS-Interop bin ich mir nicht sicher, ob das Gleiche möglich ist, und ich habe noch keine gute verallgemeinerte Lösung dafür in einem Web-Framework gesehen.

SyncFusion hat einige Virtualisierungskomponenten, nämlich eine Listenansicht - keine Ahnung, wie sie funktionieren, aber ich benutze sie. Vielleicht möchten Sie sie überprüfen.

Es gibt auch https://github.com/SamProf/BlazorVirtualScrolling, das ebenfalls einen Blick wert ist.

Oh ja das habe ich gesehen. Schön zu wissen, dass es bei dir gut funktioniert. Es hat die erheblichen Einschränkungen, dass eine einheitliche Artikelhöhe erforderlich ist und die Höhe im Voraus bekannt ist. Aber das könnte eine Zwischenlösung sein.

Kann jemand dieses Problem mit dem blazor-wasm-Tag markieren? Es ist schwer, dieses Problem inmitten all der serverseitigen (oder Hosting-agnostischen) Blazor-Probleme zu finden.

Und für diejenigen, die einen Überblick über die Arbeit von Mono WASM AOT suchen, habe ich diesen Link gefunden:
https://github.com/mono/mono/projects/11

Dein Wunsch ist mein Befehl 😆

Danke das ist sehr hilfreich!

Ist es möglich, auch nur vage Schätzungen zu erhalten, wann wir AOT-kompiliertes WASM mit Blazor verwenden können, sogar experimentell? 6 Monate? Ein Jahr? Hat irgendjemand im Blazor-Team es tatsächlich erfolgreich zum Laufen gebracht, sogar ad hoc?

Es ist ein wenig riskant, viel Zeit in Blazor zu investieren oder zu planen, wenn wir immer noch nicht wirklich wissen, wie das Endprodukt aussehen wird. So gut wie serverseitig ist, brauchen wir wirklich eine zuverlässige und performante clientseitige Version, damit dies praktikabel ist.

Ich habe diese Frage hier https://github.com/mono/mono/issues/10222 gepostet, aber die Antwort erhalten, dass dies ein falscher Ort ist. Hier neu posten:

Es wurde angekündigt, dass Blazor WASM im Mai 2020 veröffentlicht wird. Können wir davon ausgehen, dass es sich zu diesem Zeitpunkt um eine native WASM-Anwendung handelt? Was ist die korrekte Antwort?

1. Jawohl.
2. Wir werden es versuchen, aber wir sind uns nicht sicher.
3. Nein, es wird im November 2020 mit .NET 5.0 verfügbar sein.
4. Nein, und wir haben noch keine Roadmap.

Für alle Blazor-Fans sind zwei Dinge sehr wichtig:

• Laufzeitgeschwindigkeit - Interpreter ist in einigen Anwendungsfällen zu langsam.
• Downloadgröße - hoffentlich werden Sie in der Lage sein, eine WASM-Größe ähnlich der aktuellen .NET-DLLs zu erreichen und wir werden in der Lage sein, mono.wasm vollständig zu entfernen (ich glaube, diese Datei enthält nur IL-Interpreter - habe ich recht?).

Ich bin von Anfang an ein großer Fan von Blazor. Ich weiß, dass die Blazor-Serverseite für einige Leute einige Vorteile hat, aber wir alle warten auf eine echte Revolution - schnelles und zuverlässiges Blazor im Browser.

Danke Jungs für eure Mühe!!!

@Andrzej-W Dies könnte für jeden, der dies überfliegt und davon ausgeht, dass November 2020 die kanonische Veröffentlichung ist, etwas irreführend sein.

Persönlich habe ich gehört, dass es offiziell um das erste Quartal 2020 herum erscheinen soll.

Realistischerweise hindert uns derzeit nichts daran, es in unsere Build-Prozesse zu implementieren, soweit ich weiß, abgesehen von der aufgeblähten Größe der ausführbaren Datei und der Tatsache, dass es von Microsoft noch nicht unterstützt wird.

Realistischerweise hindert uns derzeit nichts daran, es in unsere Build-Prozesse zu implementieren, soweit ich weiß, abgesehen von der aufgeblähten Größe der ausführbaren Datei und der Tatsache, dass es von Microsoft noch nicht unterstützt wird.

Hat das jemand probiert? Ich denke, es ist wichtig für uns, zumindest einen Proof of Concept zu haben, damit wir sehen können, wie es im Vergleich zur interpretierten und im Vergleich zur Serverseite abschneidet. Ich weiß, dass die EXE-Größe etwas ist, an dem das Mono-Team arbeitet, und es ist wichtig, aber die App-Geschwindigkeit ist der König. (Und die Kompilierungszeit ist IMHO wirklich irrelevant, da wir das Debugging serverseitig durchführen und nur zur Veröffentlichung in natives WASM kompilieren. Die Kompilierungszeit für Webpack kann auch ziemlich grausam sein).

Auf der .NET Conf haben wir angekündigt, dass die erste Veröffentlichung von Blazor WebAssembly für Mai 2020 geplant ist. Für diese erste Veröffentlichung von Blazor WebAssembly erwarten wir, dass die Laufzeit weiterhin auf dem IL-Interpreter basiert, den wir derzeit verwenden.

Das .NET-Runtime-Team arbeitet an der Unterstützung der vorzeitigen Kompilierung für die direkte Kompilierung in WASM. Dieser Ansatz hat den Vorteil, dass die Laufzeitleistung verbessert wird, jedoch auf Kosten der App-Größe.

Für die erste Veröffentlichung von Blazor WebAssembly im Mai untersuchen wir die Ausführung des IL-Interpreters in einem gemischten Modus, in dem Hot Paths zu WASM kompiliert wurden, der Rest der App jedoch aus .NET-Assemblys besteht. Dies bietet einen guten Kompromiss zwischen Laufzeitleistung und App-Größe. Es ist jedoch noch nicht klar, ob diese rechtzeitig für Mai landen wird.

Längerfristig möchten wir ein SDK bereitstellen, das dem App-Entwickler die Kontrolle darüber gibt, welche Teile seiner App direkt in WASM kompiliert werden. Es gibt noch keine Roadmap, wann ein solches SDK verfügbar sein wird.

@lewing @richlander

Danke @danroth27 für die Erklärung. Die Downloadgröße kann durch serverseitiges Prerendering teilweise maskiert werden – stellen Sie sicher, dass https://github.com/danroth27/ClientSideBlazorWithPrerendering in allen zukünftigen Blazor-(Pre-)Releases funktioniert.

@danroth27 danke für das Update! Eine Klarstellungsfrage: Bezieht sich "das .NET-Runtime-Team" auf das Mono-Team, CoreRT, .NET 5 oder etwas anderes?

@legistek Sie sind jetzt alle ein Team : smile:. Die Technik basiert jedoch auf der Mono-Laufzeit.

Ach richtig, hab ich vergessen. ;D Worauf ich hinaus wollte war, ob mono/wasm/10222 die richtige Ausgabe/Repo für Informationen zu diesem Thema ist.

@legistek Yup , die gesamte .NET WASM-Funktion findet derzeit im Mono-Repo statt.

Ich habe jetzt eine ziemlich komplexe App erstellt, auf der Blazor serverseitig ausgeführt wird, und sie funktioniert sehr gut. (WASM über den IL-Interpreter ist jedoch so langsam, dass er unbrauchbar ist).

Ich möchte unbedingt wissen, wie es mit kompiliertem WASM laufen würde.

Wenn wir die Downloadgröße oder die Kompilierzeit nur für den Moment ignorieren, gibt es dann eine Möglichkeit, eine Blazor-App mit AOT in WASM zu kompilieren und auszuprobieren? Drüben im Mono-Repo (https://github.com/mono/mono/issues/10222) posten die Leute einige Beispiele für AOT mit anderen Plattformen wie Uno, aber ich habe noch kein Blazor-Beispiel gesehen, geschweige denn Anweisungen dazu es zu tun.

Mir ist klar, dass der Build-Prozess zu diesem Zeitpunkt völlig ad hoc wäre, aber ist es auch im Prinzip möglich, nur damit wir den Leistungsunterschied auch nur grob einschätzen können? Ich mag die Serverseite zum Debuggen und Demon, aber ich weiß nicht, ob sie für eine skalierte Produktionsbereitstellung geeignet ist. Daher zögere ich, noch viel mehr an diesem Projekt zu arbeiten, bis ich weiß, dass die Leistung auf AOT WASM gut sein wird. Ich muss mir vorstellen, dass viele Leute im selben Boot sitzen.

Zur Nachverfolgung habe ich den Uno WASM-Bootstrap mit WSL ( hier beschrieben) ausprobiert und er funktioniert wirklich recht gut. Dieses Problem hier ist immer noch als BLOCKIERT markiert und obwohl ich weiß, dass sie immer noch daran arbeiten, die Nutzlastgröße zu reduzieren, scheint es nicht so zu sein, als ob es die Arbeit an einer AOT-Build-Kette für Blazor blockieren sollte, selbst wenn es sich im Moment nur um Linux handelt. Geht das so und wenn nicht, worauf wartet das Blazor-Team vom Mono-Team, bevor es damit beginnt?

@legistek hast du deine App erstellt oder etwas anderes? Wie viel besser ist die Leistung? Haben Sie einige Metriken zu teilen? Aus Neugier fragen.

Ich habe eine Teilmenge meiner App erstellt und dann nur einige Leistungsmetriken ausgeführt, da ich das Ganze nicht ohne Blazor-Bootstrapping ausführen konnte.

Für Mathematik (Zufallszahlengenerierung und einfache Arithmetik) fand ich AOT etwa 40x schneller als interpretiert.

Was mich wirklich interessierte, waren Dinge, von denen ich wusste, dass sie ineffizient sein würden, wie Reflexion und Saitenmanipulation. Meine App verfügt über ein benutzerdefiniertes Datenbindungsframework, das WPF ähnelt, daher habe ich versucht, eine komplexe Datenbindung einzurichten und den Wert 10.000 Mal in eine zufällige Zeichenfolge zu ändern. Hier die Ergebnisse:

Mono interpretierte IL: 2,49s
Volle AOT (Chrom): 0,702 s
Volle AOT (Firefox): 0,5s
Nativ: 0,067s

Im Grunde haben wir also ein Worst-Case-Szenario, bei dem AOT etwa 4x so schnell ist wie interpretierte IL, aber ein Best-Case-Szenario von bis zu 40x.

Ich denke, das ist wahrscheinlich zu erwarten.

Leider sagt uns dies immer noch nicht, wie gut Blazor AOT im Vergleich zu interpretiert abschneiden wird, aber ich bin ein wenig pessimistisch, dass es auf der unteren Seite (4-5x) sein wird, weil Blazor vermutlich viel Saitenmanipulation macht, um zu bauen das DOM und auch ein ausgeklügeltes SPA werden viele JSON-API-Aufrufe durchführen (die natürlich ausgiebig Reflection und Strings verwenden). Aber wir können uns nicht sicher sein, bis wir tatsächlich eine echte Blazor-App mit AOT ausprobieren können.

Ich kann mir vorstellen, dass sich die Leistung in naher Zukunft erheblich verbessern wird, wenn Browser-Hersteller WebAssembly ernster nehmen.

Ich denke, AOT verdient früher als später viel mehr Untersuchungen, da Blazor wahrscheinlich von dem Ruf seiner clientseitigen Implementierung in WASM leben oder sterben wird.

Projekte wie https://d07riv.github.io/diabloweb/ beweisen ohne Zweifel, dass WebAssembly mehr als in der Lage ist, sich selbst zu bewältigen, aber ich habe noch keinen ebenso beeindruckenden Proof of Concept gesehen, der auf Mono + WASM läuft.

Dieses Thema ist für zwei Jahre offen. Gibt es Fortschritte?

@partyelite Ja, es gab Fortschritte. Es gibt eine Implementierung der AoT-Kompilierung in WASM im https://github.com/mono/mono-Repository und die Laufzeit wurde aktualisiert, um die Ausführung einer Mischung aus .NET IL und kompilierten WASM-Dateien zu unterstützen. Die AoT-Unterstützung wird jedoch für das kommende Mai-Release nicht bereit sein. Wir werden den Versand für .NET 5 erneut prüfen.

Ich habe die AOT-Kompilierungsoption ausprobiert, auf die sich Dan bezieht, und sie funktioniert gut mit Uno.

Worüber ich mir immer noch am Kopf kratze, ist, warum es noch nicht mindestens einen PoC davon mit Blazor gibt? Mir ist klar, dass die Toolchain immer noch Linux ist und die Ausgabedateien viel größer sind, als wir letztendlich wollen, aber was hindert uns daran, ein Beispiel für eine Blazor-App zu erstellen, die mit AoT funktioniert, damit wir Leistung und Machbarkeit beurteilen können?

Ich bin mir nicht sicher, ob dies zusammenhängt, aber im Syncfusion-Repository wurde vor einiger Zeit ein Leistungsproblem gemeldet (https://github.com/syncfusion/blazor-samples/issues/50), das angeblich verursacht wird durch die langsame Leistung von Mono.

In meiner Analyse reduziert sich das Leistungsproblem auf den Aufruf von js_to_wasm :

Wird das von diesem und dem Mono-Team gelöst? Oder ist das etwas unzusammenhängendes?

@Herdo könnte damit zusammenhängen: https://github.com/dotnet/aspnetcore/issues/5617

Überprüfen Sie Ihr Webkonsolen-Protokoll, um zu sehen, ob die GC-Funktion übermäßig stark ist. Dies scheint in die WASM Mono-Laufzeit eingebettet zu sein und muss IMO konfigurierbar sein.

@honkmother ,
Können Sie uns bitte mehr Informationen darüber geben, wie es Ihnen gelungen ist, Blazor-DLLs mit ILRepack zu packen? Ich habe ILRepack.MSBuild.Task wie hier beschrieben verwendet . Das Packen ist erfolgreich, aber wenn ich die Anwendung ausführe, erhalte ich immer diese Fehlermeldung:

WASM: System.IO.FileNotFoundException: Datei oder Assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' oder eine ihrer Abhängigkeiten konnte nicht geladen werden.

Es scheint, dass die Verpackung etwas kaputt macht oder einen korrekten Bootstrap der Anwendung verhindert.

hmm AOT ist in UNO . Können Sie diese Lösung C&P?

.Net 5 unterstützt die AoT-Kompilierung für Blazor nicht?

Es ist auch von der Roadmap gestrichen.

Ich würde gerne einen offiziellen Kommentar hören, bevor ich voreilige Schlussfolgerungen ziehe, aber wenn das wahr ist, sind dies sehr schlechte Nachrichten, die nicht nur Blazor betreffen, sondern mich zwingen würden, .NET selbst als Frontend-Plattform neu zu bewerten.

Auch auf der Mono-Seite wurden seit Monaten keine Aktivitäten gemeldet:
https://github.com/mono/mono/issues/10222

Vielleicht ist es an der Zeit, Verluste zu reduzieren und sich stattdessen auf CoreRT zu konzentrieren.

@ram16g @legistek Wir arbeiten daran, die Laufzeitleistung von Blazor WebAssembly in .NET 5 (und darüber hinaus) zu

Hallo @danroth27 , die Gesamtleistung Moment nicht so sehr aber wie

Hallo @MichaelPeter. Die anfängliche Seitenladezeit wird durch das Herunterladen der App und das Starten der Laufzeit dominiert. AoT wird da nicht wirklich helfen. AoT soll die Laufzeitleistung verbessern und nicht die Downloadgröße der App reduzieren. Für JIT-basierte Laufzeiten kann AoT die Startleistung verbessern, da Sie die Notwendigkeit von JIT zur Laufzeit vermeiden, aber Blazor WebAssembly verwendet eine IL-Interpreter-basierte Laufzeit ohne JIT-Unterstützung.

Aller Wahrscheinlichkeit nach wird AoT die App beim Herunterladen tatsächlich größer machen, da .NET IL ein kompakteres Format als seine nativ kompilierte Darstellung ist. Die Verwendung von AoT führt daher wahrscheinlich zu einem Kompromiss zwischen der Beschleunigung der Laufzeitleistung auf Kosten einer erhöhten Downloadgröße. Die aktuelle Überlegung ist, dass wir Entwicklern die AoT-Toolchain zur Verfügung stellen, damit Sie entscheiden können, wie viel von Ihrer App Sie AoT verwenden möchten, und dann wird die App in einem gemischten Modus ausgeführt, wobei ein Teil der App noch als .NET IL läuft , während die leistungskritischen Pfade in WebAssembly vorkompiliert sind.

Um die Startleistung der App zu verbessern, prüfen wir weitere Verbesserungen am .NET IL-Linker und arbeiten auch an den Kern-Framework-Bibliotheken, um sie besser verknüpfbar zu machen. Wir planen auch, die Startleistung der Laufzeit selbst nach dem Herunterladen zu untersuchen.

@danroth27 Gibt es irgendwelche Probleme, die ich bezüglich des Fortschritts bei der App-

@danroth27 :+1: Vielen Dank für die Info, ich nutze Blazor meistens in LAN-Umgebungen, wo Downloadzeiten fast Null sein sollten und dachte, dass der Browser das zwischenspeichert. Net-DLLs sowieso. Aber an einer Startup-Ausgabe wäre ich auch sehr interessiert.

Bitte beachten Sie, dass die Startzeiten für WebAssembly-basierte Anwendungen wie den Blazor-Interpreter davon abhängen können, ob der Browser die Dateien ordnungsgemäß zwischenspeichert. Wenn der Webserver, der Ihre Anwendung hostet, falsch konfiguriert ist oder sich die Datei geändert hat oder der Browser die Anwendung aus anderen Gründen nicht zwischenspeichern kann, muss er sie bei jedem Start der Anwendung von Grund auf neu kompilieren. Im Idealfall kann der Browser es zwischenspeichern, sodass zukünftige Besuche nach Ihrem ersten Besuch viel schneller beginnen.

Informationen dazu finden Sie unter https://v8.dev/blog/wasm-code-caching . Firefox hat einen ähnlichen Mechanismus, und ich glaube, Safari tut es auch, aber ich bin mir nicht sicher.

@danroth27 Ich schätze die Erklärung und die Position, in der Sie versuchen, .NET 5 zusammen mit allem anderen

Der erste Schritt zu AoT besteht darin, Blazor WebAssembly so zu verschieben, dass die gleichen .NET-Kernbibliotheken verwendet werden, die von .NET Core verwendet werden, was auch die Leistung verbessern sollte

Ich nehme an, Sie beziehen sich auf den Wechsel von der Mono-mscorlib zu CoreFX? Ich denke, das ist ein ausgezeichneter Schritt, wenn man die vielen veröffentlichten Leistungsbenchmarks bedenkt, die zeigen, dass CoreFX Mono (und NetFX) deutlich übertrifft.

Dann müssen wir herausfinden, wie AoT mit IL-Verknüpfung gut funktioniert.

Ja, das Verlinken ist seit einiger Zeit eine große Hürde, wie hier besprochen wurde . Dennoch ist es Uno gelungen, eine Toolchain zu erstellen und ein Gleichgewicht zwischen interpretiert und kompiliert zu finden, das App-Größen im Bereich von ~ 10 MB oder im unteren Teenagerbereich erreichen kann. Ich hätte gedacht, dass wir auf der Blazor-Seite zumindest einen PoC dafür haben, nur um mit der Messung der Leistungskennzahlen zu beginnen. Es ist im Moment am besorgniserregendsten, keine Ahnung zu haben, um welchen Grad sich die Leistung verbessern wird.

Wir planen auch, die Startleistung der Laufzeit selbst nach dem Herunterladen zu untersuchen.

Der DOM-Baustein davon muss ebenfalls sorgfältig betrachtet werden. Das Laden einer leeren Blazor-App dauert auf meinem Desktop 1-2 Sekunden und auf dem Handy noch ein paar Sekunden. Da ich in der Angular-Welt gelebt habe, bin ich es gewohnt, jedes Mal "Loading ..." zu sehen und finde die Startzeit in Ordnung. Das größere Problem sind die unerträglich langsamen Geschwindigkeiten beim Aufbau komplexer DOMs. Selbst DOMs mit 1000-2000 Elementen fügen beim anfänglichen Laden 5-10 Sekunden hinzu, und Interaktivität mit komplexen Elementen führt ebenfalls zu einer erheblichen Verzögerung. Ich sehe nicht, dass darüber viel gesprochen wird und ich mache mir Sorgen, dass (1) AOT das nicht lösen wird, weil es endemisch für WASM/JS-Interop ist und die Art und Weise, wie Strings zwischen den beiden ausgetauscht werden; und (2) der Rendering/Diffing-Mechanismus in Blazor ist jetzt so eingebaut, dass es zu spät ist, ihn in etwas zu ändern, das eine hohe Leistung bietet.

Die aktuelle Überlegung ist, dass wir Entwicklern die AoT-Toolchain zur Verfügung stellen, damit Sie entscheiden können, wie viel von Ihrer App Sie AoT verwenden möchten, und dann wird die App in einem gemischten Modus ausgeführt.

Genau wie Uno es bereits tut,...

Hier ist also meine Reaktion und Analyse auf all das, und ich möchte, dass Sie und alle anderen verstehen, dass ich hier als jemand ankomme, der wahrscheinlich ein so großer .NET- und Microsoft-Fan ist wie je zuvor. Blazor wurde der Welt als Framework für die Verwendung von _webassembly_ vorgestellt, um .NET wieder in den Browser zu bringen. Ich war begeistert, als ich davon erfuhr. Aber es ist jetzt über zwei Jahre her, seit es zum ersten Mal für die Vorschau eingeführt wurde, und das Webassembly-Teil ist aufgrund der schwerwiegenden Leistungsprobleme immer noch nicht für Verbraucheranwendungen bereit. Inzwischen wurde viel in Server-Side (wobei ich mir noch nicht ganz sicher bin) und jetzt vielleicht mobil durch Xamarin investiert, aber die WASM kann immer wieder auf die Straße geworfen werden.

.NET hat als Frontend-Webplattform so viel an Boden verloren, seit SPAs die Macht übernommen haben und Silverlight dank des Chrome-Verbots von Plugins gestorben ist. Blazor hätte das alles ändern können. Aber ich kann im Moment nicht sagen, ob Blazor WASM wirklich von Microsoft als strategischer Game Changer gedacht ist oder nur eine Kuriosität für Fanboys wie mich. Aber Fanboy oder nicht, wie kann ich als Geschäftsinhaber, wenn ich heute ein Frontend-Framework für ein neues Projekt oder einen Umbau eines alten auswähle, meinen Unterstützern gegenüber rechtfertigen, dass Blazor der richtige Weg ist, über React oder Angular? Wenn ich die Vor- und Nachteile aufliste, was bleibt mir als Profi, außer dass ich C# mag? Die Nachteile hingegen nehmen immer weiter zu.

Daher bin ich sehr enttäuscht und ein wenig demoralisiert. Es muss nicht nur länger warten, es gibt immer noch viele Zweifel, ob diese Technologie jemals lebensfähig sein wird, und ich für meinen Teil hatte darauf gewartet, AoT zu sehen, damit ich diese Entscheidung treffen konnte.

Ich erwarte nicht, dass Sie heute Ihre Roadmap ändern oder wirklich in der Lage sind, diese Bedenken auszuräumen, aber ich dachte, sie wären es wert, geäußert zu werden. Ich möchte unbedingt, dass dies gelingt und würde nichts lieber tun, als .NET seinen Platz als König der interaktiven Web-Apps zurückzuerobern. Aber wenn ich heute Geld investieren müsste, sieht es nicht nach einer guten Wette aus. Bitte beweisen Sie mir das Gegenteil!

Ich muss sagen, dass ich in der gleichen Situation bin wie @legistek. Ich verwende Blazor ab Version 0.1 und bin ein großer Fan dieser Technologie. Natürlich ist es für einige von uns schön, eine Option zu haben, Blazor auf dem Server auszuführen. Es ist auch eine interessante Option, Blazor auf dem Handy zu haben, aber ich glaube wirklich, dass die WebAssembly-Implementierung die höchste Priorität haben sollte. Es ist der Game Changer, es ist die Zukunft.

@danroth27 für blazor Die JSON-Deserialisierungsgeschwindigkeit ist für größere Objektlisten extrem langsam.

Ich finde, dass dies der schlimmste Performance-Hit in Blazor ist, wenn Rest-APIs verwendet werden und die Datengrößen größer sind, während Javascript nicht annähernd gleich von der Größe beeinflusst wird.

Wenn es einen manuellen Deserialisierungsprozess erfordert, der für diese größeren Listen in Ordnung wäre, fragen Sie sich nur, ob es dazu eine Anleitung gibt. Im Idealfall wären wir in der Lage, die Deserialisierer zu AOT zu machen?

Um die Startzeit zu verkürzen, empfehle ich Lazy Loading. Das bedeutet, dass nur DLLs geladen werden, die für diese bestimmte Ansicht oder Seite erforderlich sind. Das würde den Start in der Tat beschleunigen

@ram16g @legistek Wir arbeiten daran, die Laufzeitleistung von Blazor WebAssembly in .NET 5 (und darüber hinaus) zu

Hallo zusammen und @danroth27 , wie sehr wird dies die Startgeschwindigkeit verbessern (vorausgesetzt, alle Inhalte sind zwischengespeichert)? Was kann ich tun, um bis November aot zu liefern? Ich mag es nicht mehr eckig zu verwenden. ahahahaha Ich bin bereit, kostenlose Codierung anzubieten, nur um dies zu beschleunigen. Ich interessiere mich nicht wirklich für die anfängliche Downloadgröße, da sie nur zwischengespeichert wird. Benutzer sind häufige Besucher. angle kann sofort starten, wenn Dateien zwischengespeichert werden.

@hoksource Wir haben keine genauen Zahlen darüber, wie sich die Perf-Eigenschaften ändern werden, aber wenn Sie die Vorschauen in 1-2 Monaten ausprobieren, sollten Sie es herausfinden können.

@hoksource Wir haben keine genauen Zahlen darüber, wie sich die Perf-Eigenschaften ändern werden, aber wenn Sie die Vorschauen in 1-2 Monaten ausprobieren, sollten Sie es herausfinden können.

@SteveSandersonMS ok so
Um einen Beitrag zu leisten, wird mein Ziel sein, Folgendes tun zu können:

Option 1: Direkter Ansatz (das Problem direkt angehen):
[ ] Mono-Projekt kompilieren lernen
[ ] lernen, asp.net blazor-Projekt zu kompilieren
[ ] lernen, einen asp.net-blazor mit webassembly zu kompilieren
[ ] lernen, das Blazor-Client-Programm vollständig in Webassembly zu kompilieren (ist mono->webassembly aot fertig? Kann es alle Referenz-Binärdateien in 1 wasm-Datei kombinieren?)
[ ] Überprüfen Sie, ob Mono ein ganzes Webassembly-Projekt in eine Webassembly kompilieren kann.
[ ] Finden Sie heraus, wie Sie alle fehlenden c#/.net-Sprachen für die Webassembly unterstützen können
[ ] Finden Sie die optimale Verknüpfungsstruktur heraus, um alle DLLs in 1 wasm oder mehrere wasm-Dateien zu konvertieren
[ ] Finden Sie heraus, wie Sie Dateigröße und Leistung am besten abwägen
[ ] lernen/entwerfen Sie das Verknüpfen und Zusammenführen von Binärdateien zu einer Webassembly oder erlauben Sie Lazyloading mit Teilassemblys
[ ] haben verschiedene Lösungen, wählen Sie die wenigen besten Lösungen aus und präsentieren Sie sie Ihnen. über einen öffentlichen/privaten Repository-Zweig aus dem aktuellen Projekt

Option 2: (das Problem indirekt angehen)
[ ] Ich werde kleine, einfache Aufgaben wie kleine/einfache Module/Entwurf/Dokumentation erledigen, glaube daran, dass größere Ingenieure/Designer ihre Ressourcen auf den direkten Ansatz aus Option 1 vor der Veröffentlichung von nov .net 5 konzentrieren/ausrichten können.

• zusätzliche Frage. Sollen alle Referenzbibliotheken Open Source sein? Ich habe einige Bibliotheken programmiert, bin mir aber nicht sicher, ob ich sie alle öffentlich veröffentlichen möchte.

Aber ich denke, Option 1 wäre die beste Option, da ich einige andere Dinge nicht wiederholen würde, die einer von euch macht. Bitte bestätigen Sie, wenn ich etwas verpasst habe.

@hoksource Vielen Dank für Ihre Bereitschaft, sich zu engagieren. Derzeit ist die einzige praktikable Option Option 1, da das ASP.NET Core-Team voll mit anderen Arbeiten beschäftigt ist. Ich weiß, das ist eine große Anzahl von Dingen, die Sie herausfinden müssen, aber das hilft hoffentlich zu erklären, warum wir nicht einfach in den .NET 5-Meilenstein schlüpfen können :) in die Palette der Dinge, die hier benötigt werden.

zusätzliche Frage. Sollen alle Referenzbibliotheken Open Source sein? Ich habe einige Bibliotheken programmiert, bin mir aber nicht sicher, ob ich sie alle öffentlich veröffentlichen möchte.

Es liegt ganz bei Ihnen, was Sie Open Source machen und was nicht. ASP.NET Core selbst ist Open Source, aber Sie können darüber hinaus Closed-Source-Elemente erstellen, wenn Sie möchten. Wir können hier nur Open-Source-Sachen in unser Repo aufnehmen.

Für JIT-basierte Laufzeiten kann AoT die Startleistung verbessern, da Sie die Notwendigkeit von JIT zur Laufzeit vermeiden, aber Blazor WebAssembly verwendet eine IL-Interpreter-basierte Laufzeit ohne JIT-Unterstützung.

Aus Neugier: Wäre JITting auf dem Client eine praktische Alternative zum Dolmetschen/Voll-AoT?

Hallo Leute! Ich habe gerade mit einigen Teams und Dingen gesprochen. Scheint für Bibliotheken wie SkiaSharp ziemlich wichtig zu sein. Der Hauptteil von SkiaSharp ist eine native Bibliothek und die Ausgabe ist im Grunde eine .a-Datei, die statisch eingebunden werden muss. Wir _könnten_ möglicherweise eine dynamische native Bibliothek erstellen, aber unterstützt Blazor das überhaupt?

Zu Ihrer Information, es ist derzeit möglich, eine native Bibliothek statisch in die Laufzeit einzubinden. Es ist nicht etwas, was ich empfehlen würde, da es nicht trivial ist, aber Sie könnten dies tun und dann in die statisch verknüpfte Bibliothek p/invoke, sobald alle Teile da sind. Ich weiß nicht, ob wir noch Testfälle haben, die dies tun, daher ist möglicherweise eine zusätzliche Infrastruktur erforderlich, die noch nicht in Blazor ausgeliefert wird. Sie müssten Ihre eigenen dotnet.wasm/dotnet.js kompilieren, um sie in Ihre Blazor-Builds zu integrieren, was nichts für schwache Nerven ist.

Dynamische native Bibliotheken sind eine andere Sache. Meiner Meinung nach sind die Tools dafür in wasm im Allgemeinen derzeit nicht großartig, bevor Sie überhaupt zu der Frage kommen, ob Blazor sie unterstützt.

Ich habe letztes Jahr festgestellt, dass Dynamic Linking derzeit überhaupt keine praktikable Lösung ist. Emscripten impliziert, dass das "Haupt"-Wasm-Modul alle möglichen Kombinationen von Systembibliotheken enthält, die jede dynamische Bibliothek verwenden möchte. Dies macht für den Anfang ein sehr großes gemeinsames Wasm-Modul.

Ich habe eine Weile versucht, diesen Ansatz mit Uno.SkiaSharp zu verwenden, aber es war hart und legte das beiseite (an diesem Punkt hielt sich @vargaz wahrscheinlich selbst zurück, "es dir gesagt" zu sagen 😂).

Der Uno-Bootstrapper ist jetzt in der Lage, statische Verknüpfungen (Anweisungen hier ) und P/Invoke über WSL unter Windows zu verwenden, und da er dieselben Ausführungspfade verwendet, die der interne System.Native-Interop verwendet, ist er jetzt ziemlich stabil. Auf diese Weise können Sie sogar problemlos mit Rostmodulen interoperieren .

Ich habe etwas gelesen, nur die .net-Laufzeit wird in wasm konvertiert. Alle DLLs werden beim Start heruntergeladen und geparst. es sieht so aus, als ob die verwendete wasm-Laufzeit mono ist. Ihr Ziel ist es nun, stattdessen .net Core Runtime zu verwenden.

Der aktuelle Full-Aot-Compiler wird von Mono erstellt, aber ich bin mir nicht sicher, ob ein Full-Aot mit .net-Kern der Pfad/Weg sein sollte. (Keine Ahnung was ich hier sage. braucht Experten)

Internet sagt, dass .net Core für rechenintensive Aufgaben doppelt so schnell läuft wie Mono. Der Start ist io-bezogen, zuerst das Herunterladen der .dll-Binärdateien und Abhängigkeiten. (Mehrere Dateien), die sie in den Speicher parsen. Starten Sie dann die blazor wasm-Client-App darüber. Das Herunterladen dauert eine Weile (kann aber zwischengespeichert werden) und das Parsen dauert eine Weile. Der aot-Compiler weiß auch nicht, welche Abhängigkeiten von blazor und welche App-spezifisch sind. Es wird chaotisch, wenn Sie immer festlegen, welche DLL in aot wasm eingeschlossen werden soll. Also ein Full Aot sieht gut aus. (Aber es wird schneller mit .net Core Runtime-Implementierung anstelle von Mono sein? Ich bin mir wieder nicht sicher) Ich bin mir auch nicht sicher, ob das Design / die Implementierung der vollständigen Aot-Wasm-Kompilierung mit Mono- oder .net-Laufzeit erfolgt. Auch nicht sicher über den Fortschritt

@danroth27 Gibt es Fortschritte?

Wird es in .NET 5 verfügbar sein?
Es wäre schön, eine Vorabversion zu haben, um diese Funktionalität auch zu überprüfen ;)

@redradist AOT wird von .NET 5 nicht mehr danroth27 kommentar

@hoksource

@redradist AOT wird von .NET 5 nicht mehr danroth27 kommentar

Es ist traurig :(

Ich habe eine Frage. Mit Blazor AOT arbeiten Sie an:

1. Kompilieren von C# direkt in das WebAssembly-Bytecode-Format
2. oder arbeiten Sie daran, in .NET-DLLs kompilierte IL in das WebAssembly-Bytecode-Format umzuwandeln

Der Ansatz 2) würde alle .NET-Tools (einschließlich unserer) beibehalten, die auf Standard-IL und kompilierten Metadaten sowie auf PDB angewiesen sind, um zu funktionieren. Auch 2) hätte den zusätzlichen Vorteil, dass System DLLs auch zu WebAssembly kompiliert werden, möglicherweise mit Code, der nicht zur Laufzeit bereinigt wird (siehe das
Vielen Dank

Übrigens, es gibt viele Ressourcen über Blazor, aber ich habe nicht diejenige mit der richtigen Granularität gefunden, um mich über Blazor Internals zu informieren, also habe ich sie geschrieben.

2 nicht 1

Außerdem hoffe ich, dass der AoT-Prozess geeignete Quellzuordnungen (von wasm bis C#) generiert, um das Debuggen viel einfacher zu machen.

Ich hoffe, diese Unterstützung im ersten Quartal 2021 für .Net 6-Vorschauversionen zu sehen. Dies ist grundlegend, um Repositorys wie SkiaSharp zu unterstützen, die nativ im Webbrowser ausgeführt werden.

Danke, dass sie uns kontaktiert haben.
Wir verschieben dieses Problem zur zukünftigen Bewertung/Überlegung Next sprint planning Meilenstein hier .