Aspnetcore: Compilation AoT

Suivi du statut de mono-wasm

Connaissez-vous un problème pour lequel nous pouvons suivre les progrès à ce sujet ?

Le mode interprète actuel est très lent.
https://dotnetfiddle.net/JUpsRT

.NET 300 ms
WASM : 13155 ms

Oui, nous pensons que cela est davantage dû au fait que rien n'a encore été optimisé qu'une indication que nous devrions passer à AoT à ce stade, mais nous en saurons plus à mesure que l'interpréteur IL et le support AoT arriveront à maturité.

@ danroth27 D'après ce que je peux dire, la différence de performances entre l'interpréteur Mono IL et la version mono.wasm actuelle est d'environ 5 à 10x. Globalement, mono.wasm est environ 50-80x et l'interpréteur IL environ 10 fois plus lent qu'une application de console .NET Core native.

Ainsi, l'interpréteur n'est actuellement toujours pas très rapide dans l'ensemble et WebAssembly ajoute encore plus de temps système en plus de cela.

Je suppose qu'AOT a probablement encore de meilleures chances d'accélérer les choses, mais vous avez raison de dire qu'il est probablement trop tôt pour exclure l'interpréteur, car la plupart des applications Web n'ont même pas des exigences de performances aussi élevées et ira très probablement bien avec une version interprétée.

AOT étant plus efficace n'est pas seulement important pour les applications intensives. Cela est également important pour les plates-formes mobiles et autres plates-formes bas de gamme, en particulier lorsque l'on considère l'utilisation de la batterie.

Existe-t-il actuellement un moyen possible d'activer la compilation AoT pour les projets Blazor ? Je continue de lire des articles de blog qui prétendent que Blazor a déjà un mode AoT ; Si cela est vrai, quelqu'un pourrait-il indiquer un article expliquant comment l'activer ?

@TheFanatr la compilation AOT dépend de la prise en charge mono de cette fonctionnalité. Pour autant que je sache, la dernière mise à jour sur le sujet @migueldeicaza dans le Blazor Gitter .

Miguel de Icaza (2018-06-08 19:01):
Nous y travaillons. Ce qui s'est passé est ceci :
L'interpréteur utilise "emscripten" qui a une libc assez complète sur laquelle nous pouvons compter. Et notre moteur AOT a été construit sur du LLVM pur, ce qui nous oblige à écrire la libc complète. Ce dernier est l'endroit idéal, car nous obtenons des liens natifs et un support llvm immédiat, etc. Mais cela nous obligerait à écrire cette libc.
Donc, à court terme, nous nous dirigeons vers emscripten le compilateur AOT, assurez-vous que nous gardons la compatibilité. L'inconvénient est que l'outillage emscripten est plus ancien, donc bon nombre des meilleurs éléments comme l'éditeur de liens LLVM ne sont pas disponibles. Nous travaillons donc sur ces choses.
Fondamentalement, nous avions fait quelque chose, mais nous devions repartir de zéro pour travailler avec ce que nous avons sans nous forcer à écrire et à tout imiter par nous-mêmes. Nous aurions pu essayer de mélanger les deux, mais c'est aussi un effort majeur. Nous pensons donc que nous pouvons faire emscripten pour l'instant via quelques hacks astucieux ici et là.

Donc, en bref, ils y travaillent, mais il n'y a pas de bonne option pour le faire avec les versions publiques actuelles.

Des progrès assez importants viennent d'être signalés dans CoreRT !!

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

quelqu'un a une idée de ce qui bloque ça ? Je serais peut-être prêt à consacrer quelques milliers de milliards d'heures de travail pour que l'AOT se produise plus tôt que plus tard, maintenant que les pouvoirs en place chez Microsoft se sont engagés à blaser côté client. AOT va être vraiment important si nous voulons développer des PWA (excellents) avec Blazor.

@honkmother AoT est en cours d'élaboration par les gens de mono.wasm dans le référentiel https://github.com/mono/mono . Je suis sûr qu'ils seraient ravis d'avoir votre aide! Ce problème suit la consommation de leur travail une fois qu'il est prêt.

Je pense que j'ai une question quelque peu connexe, mais elle n'est pas bien pensée et mal formulée. J'ai expérimenté ILRepack et Blazor et j'ai réussi à regrouper la plupart des dll dans un seul blob monolithique. Avez-vous l'intention de regrouper à un moment donné les bibliothèques communes en une seule DLL ?

@honkmother Nous n'avons actuellement aucun plan concret pour le faire, mais nous serions intéressés d'entendre les résultats de votre expérimentation.

J'ai pu fusionner la plupart d'entre eux en utilisant simplement ILRepack sur la sortie /dist/bin/, et en incluant System.Core.dll. Les temps de démarrage ont été améliorés après avoir combiné la plupart des bibliothèques, mais cela a introduit de nombreux bogues grinçants que je ne sais pas comment résoudre; et bien sûr, vous perdez la possibilité de compter sur la mise en cache des morceaux de code mis à jour sans avoir à télécharger à nouveau l'intégralité du blob.

Y a-t-il eu des développements à ce sujet ou au moins un ETA ? Le côté serveur fonctionne assez bien, mais les performances WASM côté client via l'interpréteur sont toujours inacceptables dès que le DOM devient raisonnablement complexe.

Je ne pense pas, l'AOT sur le dépôt mono semble toujours être un WIP ; J'ai entendu dire que nous l'aurons d'ici le premier trimestre de 2020, mais je ne sais pas si c'est certain ; ce qui est triste car j'ai une très belle PWA configurée côté client, mais elle présente des problèmes de performances qu'AOT réduirait probablement sans avoir besoin de hacks sales.

En attendant, vous pouvez faire certaines choses pour soulager la douleur, à savoir utiliser le DOM virtuel et/ou utiliser directement RenderTreeBuilder afin que vous ne rendiez pas tout en même temps et que vous ayez un certain contrôle sur ce qui se passe.

Eh bien, je me demandais aussi si quelque chose avait changé à la lumière de l'annonce il y a quelques mois concernant .NET 5 . Citation intéressante là :

Le projet Blazor utilise déjà le Mono AOT. Ce sera l'un des premiers projets à passer à .NET 5. Nous l'utilisons comme l'un des scénarios pour prouver ce plan.

Savent-ils quelque chose que nous ne savons pas ?

En attendant, vous pouvez faire certaines choses pour soulager la douleur, à savoir utiliser le DOM virtuel et/ou utiliser directement RenderTreeBuilder afin que vous ne rendiez pas tout en même temps et que vous ayez un certain contrôle sur ce qui se passe.

En effet. Je crée un framework MVVM à partir de zéro inspiré de WPF et l'une des premières choses que je fais est de remplacer ShouldRender pour désactiver les déclencheurs de rendu automatiques de Blazor et à la place, compter sur les modifications de propriétés pour indiquer aux composants quand effectuer un nouveau rendu. En fait, une amélioration des performances HUUUUGGGE vient de la mise à jour des styles via l'interopérabilité JS, plutôt que de StateHasChanged , dans la mesure du possible.

Néanmoins, j'ai des problèmes lorsque de grands DOM doivent être générés à l'avance - par exemple, une liste complexe ou une grille de données. Le côté serveur est bien, mais le côté client prend parfois 5 à 10 secondes juste pour le rendu initial.

Ce dont nous avons vraiment besoin, c'est d'un VirtualizingPanel comme dans WPF. J'ai longuement réfléchi à la façon dont cela pourrait être implémenté dans l'interopérabilité Blazor et JS, mais une solution complète m'échappe toujours. Dans WPF, cela fonctionne car le framework est chargé de mesurer chaque élément visuel et de signaler sa taille. Même avec l'interopérabilité JS, je ne suis pas sûr que la même chose soit possible, et je n'ai pas encore vu de bonne solution généralisée pour cela dans un framework Web.

SyncFusion a quelques composants de virtualisation, à savoir une vue de liste - aucune idée de comment ils fonctionnent mais je les utilise. Vous voudrez peut-être les vérifier.

Il y a aussi https://github.com/SamProf/BlazorVirtualScrolling qui vaut également le détour.

Ah oui j'ai vu ça. Heureux de savoir que cela fonctionne bien pour vous. Il a les limitations importantes d'avoir besoin d'une hauteur d'article uniforme et que la hauteur doit être connue à l'avance. Mais cela pourrait être une solution provisoire.

Quelqu'un peut-il marquer ce problème avec la balise blazor-wasm ? Il est difficile de trouver ce problème parmi tous les problèmes Blazor côté serveur (ou agnostiques en matière d'hébergement).

Et pour ceux qui recherchent un aperçu du travail en cours de Mono WASM AOT, j'ai trouvé ce lien :
https://github.com/mono/mono/projects/11

Votre souhait est ma commande

Merci c'est très utile !

Est-il possible d'obtenir même la plus vague des estimations du moment où nous pourrions commencer à utiliser WASM compilé par AOT avec Blazor, même à titre expérimental ? 6 mois? Une année? Est-ce que quelqu'un dans l'équipe Blazor a réussi à le faire fonctionner même de manière ad hoc?

Il est un peu risqué de commencer à investir beaucoup de temps dans Blazor côté client ou à planifier en conséquence alors que nous ne savons toujours pas vraiment à quoi ressemblera le produit final. Aussi bon que soit côté serveur, nous avons vraiment besoin d'une version côté client fiable et performante pour que cela soit viable.

J'ai posté cette question ici https://github.com/mono/mono/issues/10222 mais j'ai obtenu la réponse que ce n'est pas le bon endroit. Republier ici :

Il a été annoncé que Blazor WASM sortira en mai 2020. Pouvons-nous supposer qu'il s'agira d'une application WASM native pour le moment ? Quelle est la bonne réponse?

1. Oui.
2. Nous allons essayer, mais nous ne sommes pas sûrs.
3. Non, il sera disponible en novembre 2020 avec .NET 5.0.
4. Non, et nous n'avons pas encore de feuille de route.

Pour tous les fans de Blazor, deux choses sont très importantes :

• Vitesse d'exécution - l'interpréteur doit ralentir dans certains cas d'utilisation.
• Taille de téléchargement - j'espère que vous pourrez atteindre une taille WASM similaire aux DLL .NET actuelles et nous pourrons supprimer complètement mono.wasm (je crois que ce fichier contient uniquement un interpréteur IL - n'ai-je pas raison ?).

Je suis un grand fan de Blazor depuis le début. Je sais que le côté serveur de Blazor présente certains avantages pour certaines personnes, mais nous attendons tous une véritable révolution - Blazor rapide et fiable dans le navigateur.

Merci les gars pour votre travail acharné !!!

@Andrzej-W Cela peut être un peu trompeur pour quiconque parcourt cela et suppose que novembre 2020 est la version canonique.

Personnellement, j'ai entendu dire qu'il est censé sortir officiellement vers le premier trimestre de 2020.

En réalité, rien ne nous empêche de l'implémenter dans nos processus de construction pour le moment, à ma connaissance, au-delà de la taille exagérée de l'exécutable et du fait qu'il n'est pas encore pris en charge par Microsoft.

En réalité, rien ne nous empêche de l'implémenter dans nos processus de construction pour le moment, à ma connaissance, au-delà de la taille exagérée de l'exécutable et du fait qu'il n'est pas encore pris en charge par Microsoft.

Quelqu'un a-t-il essayé cela? Je pense qu'il est important pour nous d'avoir au moins une preuve de concept afin que nous puissions voir comment cela fonctionne par rapport à interprété et par rapport au côté serveur. Je sais que la taille de l'exe est quelque chose sur lequel l'équipe mono travaille, et c'est important, mais la vitesse de l'application est reine. (Et le temps de compilation n'est vraiment pas pertinent à mon humble avis, car nous allons déboguer côté serveur et compiler uniquement vers WASM natif pour la publication. Le temps de compilation pour le pack Web peut également être assez atroce).

Lors de la .NET Conf, nous avons annoncé que la première version de Blazor WebAssembly est prévue pour mai 2020. Pour cette première version de Blazor WebAssembly, nous prévoyons que le runtime sera toujours basé sur l'interpréteur IL que nous utilisons actuellement.

L'équipe d'exécution .NET travaille sur la prise en charge de la compilation à l'avance pour une compilation directe vers WASM. Cette approche a l'avantage d'améliorer les performances d'exécution, mais au détriment de la taille de l'application.

Pour la version initiale de Blazor WebAssembly en mai, nous explorons l'exécution de l'interpréteur IL en mode mixte, où les chemins actifs ont été compilés vers WASM mais le reste de l'application est constitué d'assemblages .NET. Cela offre un bon compromis entre les performances d'exécution et la taille de l'application. Cependant, il n'est pas encore clair si cela arrivera à temps pour mai.

À plus long terme, nous souhaitons fournir un SDK qui permet au développeur d'applications de contrôler quelles parties de son application sont compilées directement dans WASM. Il n'y a pas encore de feuille de route pour savoir quand un tel SDK sera disponible.

@lewing @richlander

Merci @danroth27 pour l'explication. La taille du téléchargement peut être partiellement masquée par le prérendu côté serveur - assurez-vous que cette https://github.com/danroth27/ClientSideBlazorWithPrerendering fonctionnera dans toutes les futures (pré)versions de Blazor.

@danroth27 merci pour la mise à jour ! Une question de clarification : est-ce que "l'équipe d'exécution .NET" fait référence à l'équipe Mono, CoreRT, .NET 5 ou autre chose ?

@legistek Ils sont tous une seule équipe maintenant : smile:. La technologie est cependant basée sur le runtime Mono.

Ah c'est vrai j'avais oublié. ;D Ce à quoi je voulais en venir était de savoir si mono/wasm/10222 était le bon numéro/repo pour obtenir des informations sur ce sujet.

@legistek Oui , tout le travail de .NET WASM se déroule actuellement dans le référentiel mono.

J'ai maintenant construit une application assez complexe exécutant Blazor côté serveur, et cela fonctionne très bien. (WASM via l'interpréteur IL, cependant, est si lent qu'il est inutilisable).

Je meurs d'envie de savoir comment cela fonctionnerait avec WASM compilé.

Si nous ignorons la taille du téléchargement ou le temps de compilation juste pour le moment, existe-t-il un moyen pour AOT de compiler une application Blazor sur WASM et de l'essayer? Sur le dépôt mono (https://github.com/mono/mono/issues/10222), les gens publient des exemples d'AOT avec d'autres plates-formes comme Uno, mais je n'ai pas encore vu d'exemple Blazor et encore moins d'instructions sur la façon dont pour le faire.

Je me rends compte que le processus de construction serait complètement ad hoc à ce stade, mais est-ce possible même en principe juste pour que nous puissions avoir une idée même approximative de la différence de performance ? J'aime le côté serveur pour le débogage et la démonstration, mais je ne sais pas si c'est viable pour un déploiement de production à grande échelle. J'hésite donc à travailler beaucoup plus sur ce projet jusqu'à ce que je sache que les performances sur AOT WASM seront bonnes. Je dois imaginer qu'il y a beaucoup de gens dans le même bateau.

Juste pour faire un suivi, j'ai fini par essayer le bootstrap Uno WASM en utilisant WSL (décrit ici ) et cela fonctionne vraiment très bien. Ce problème ici est toujours marqué comme BLOQUÉ et bien que je sache qu'ils travaillent toujours à réduire la taille de la charge utile, cela ne semble pas devoir bloquer le travail sur une chaîne de construction AOT pour Blazor, même s'il ne s'agit que de Linux pour le moment. Est-ce que cela se passe et sinon qu'est-ce que l'équipe Blazor attend de l'équipe Mono avant de commencer?

@legistek avez-vous

J'ai construit un sous-ensemble de mon application, puis j'ai exécuté quelques mesures de performances car je ne pouvais pas tout exécuter sans l'amorçage de Blazor.

Pour les mathématiques (génération de nombres aléatoires et arithmétique simple), j'ai trouvé que l'AOT était environ 40 fois plus rapide qu'interprété.

Ce qui m'intéressait vraiment, c'était des choses que je savais être inefficaces comme la réflexion et la manipulation des cordes. Mon application dispose d'un cadre de liaison de données personnalisé similaire à WPF, j'ai donc essayé de configurer une liaison de données complexe et de modifier la valeur en une chaîne aléatoire 10 000 fois. Voici les résultats :

IL Mono Interprété : 2.49s
AOT complet (Chrome): 0.702s
AOT complet (Firefox) : 0,5 s
Natif : 0,067 s

Donc, fondamentalement, nous avons un scénario dans le pire des cas où l'AOT est environ 4 fois plus rapide que l'IL interprété, mais un scénario dans le meilleur des cas jusqu'à 40 fois.

Je pense que c'est probablement à prévoir.

Malheureusement, cela ne nous dit toujours pas à quel point Blazor AOT fonctionnera par rapport à l'interprétation, mais je suis un peu pessimiste sur le fait que ce sera du côté inférieur (4-5x) car Blazor fait probablement beaucoup de manipulations de chaînes pour construire le DOM, ainsi qu'un SPA sophistiqué, effectueront de nombreux appels d'API JSON (qui, bien sûr, utilisent beaucoup la réflexion et les chaînes). Mais vraiment, nous ne pouvons pas être sûrs jusqu'à ce que nous puissions réellement essayer une véritable application Blazor avec AOT.

J'imagine que les performances seront remarquablement améliorées dans un proche avenir, à mesure que les fournisseurs de navigateurs commenceront à prendre WebAssembly plus au sérieux.

Je pense qu'AOT mérite beaucoup plus d'enquêtes tôt que tard, car Blazor vivra ou mourra probablement en raison de la réputation de sa mise en œuvre côté client dans WASM.

Des projets comme https://d07riv.github.io/diabloweb/ prouvent sans aucun doute que WebAssembly est plus que capable de se gérer lui-même, mais je n'ai pas encore vu de preuve de concept tout aussi impressionnante fonctionnant sur Mono+WASM.

Ce dossier est ouvert depuis deux ans. Y a-t-il des avancées ?

@partyelite Oui, il y a eu des progrès. Il existe une implémentation de la compilation AoT vers WASM dans le référentiel https://github.com/mono/mono et le runtime a été mis à jour pour prendre en charge l'exécution d'un mélange de fichiers .NET IL et WASM compilés. Cependant, le support AoT ne sera pas prêt pour la prochaine version de mai. Nous allons revoir l'expédition pour .NET 5.

J'ai essayé l'option de compilation AOT à laquelle Dan fait référence et cela fonctionne bien avec Uno.

Ce que je me demande encore, c'est pourquoi il n'y a pas encore au moins un PoC fonctionnant avec Blazor ? Je me rends compte que la chaîne d'outils est toujours Linux et que les fichiers de sortie sont beaucoup plus volumineux que nous ne le souhaitons, mais qu'est-ce qui empêche de créer un exemple d'application Blazor fonctionnant avec AoT afin que nous puissions évaluer les performances et la faisabilité ?

Je ne sais pas si cela est lié, mais sur le référentiel Syncfusion, un problème de performances a été signalé il y a quelque temps (https://github.com/syncfusion/blazor-samples/issues/50), qui serait dû à la lenteur des performances du mono.

Dans mon analyse, le problème de performances se résume à l'appel de js_to_wasm :

Est-ce quelque chose qui sera résolu par cela et l'équipe mono ? Ou est-ce quelque chose sans rapport?

@Herdo, cela pourrait être lié à ceci : https://github.com/dotnet/aspnetcore/issues/5617

Vérifiez le journal de votre console Web pour voir s'il GCing excessivement. Cela semble être intégré au runtime WASM Mono et doit être configurable IMO.

@honkmother ,
Pouvez-vous s'il vous plaît partager plus d'informations sur la façon dont vous avez réussi à empaqueter les DLL Blazor avec ILRepack ? J'ai utilisé ILRepack.MSBuild.Task comme détaillé ici . L'emballage réussit mais lorsque j'exécute l'application, j'obtiens toujours cette erreur :

WASM : System.IO.FileNotFoundException : Impossible de charger le fichier ou l'assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' ou l'une de ses dépendances.

Il semble que l'empaquetage casse quelque chose, ou que la liste empêche un démarrage correct de l'application.

hmm AOT est dans UNO . Pouvez-vous C&P cette solution ?

.Net 5 ne prendra-t-il pas en charge la compilation AoT pour Blazor ?

Il est également rayé de la feuille de route.

J'aimerais entendre les commentaires officiels avant de tirer des conclusions, mais si cela est vrai, c'est une très mauvaise nouvelle qui n'affecte pas seulement Blazor, mais qui m'obligerait à réévaluer .NET lui-même en tant que plate-forme frontale.

Aucune activité n'a été signalée depuis des mois du côté de Mono :
https://github.com/mono/mono/issues/10222

Il est peut-être temps de réduire les pertes et de se concentrer plutôt sur CoreRT.

@ram16g @legistek Nous travaillons à améliorer les performances d'exécution de Blazor WebAssembly dans .NET 5 (et au-delà). AoT est toujours sur notre feuille de route à long terme, mais cela prendra plus de temps à livrer que nous n'en avons le temps dans .NET 5. La première étape vers AoT consiste à déplacer Blazor WebAssembly pour utiliser les mêmes bibliothèques .NET de base que celles utilisées par .NET Core, qui devrait également améliorer les performances. C'est le travail qui se fait en ce moment. Ensuite, nous devons déterminer comment faire en sorte que l'AoT fonctionne bien avec la liaison IL. À ce stade, nous pensons qu'il nous faudra jusqu'au premier trimestre de l'année prochaine (premières prévisualisations de .NET 6) pour rendre publiques les premières prévisualisations de la prise en charge de .NET AoT pour WebAssembly. Mais même sans AoT, nous nous attendons toujours à apporter des améliorations de performances significatives pour Blazor WebAssembly dans .NET 5.

Bonjour @danroth27 , les performances globales ne me préoccupent pas tant pour le moment, mais qu'en est-il des performances de démarrage initiales ? Il faut 2-3 secondes à chaque visite de page jusqu'à ce que la page soit chargée, jusqu'à ce que le runtime soit chargé, les DLL compilées, etc. Y aura-t-il des améliorations sans AOT ? Ou devons-nous nous fier au prérendu ?

Salut @MichaelPeter. Le temps de chargement initial de la page est dominé par le téléchargement de l'application et le démarrage de l'exécution. AoT n'aidera pas vraiment cela. AoT est destiné à améliorer les performances d'exécution, et non à réduire la taille de téléchargement de l'application. Pour les environnements d'exécution basés sur JIT, AoT peut améliorer les performances de démarrage car vous évitez le besoin de JIT au moment de l'exécution, mais Blazor WebAssembly utilise un environnement d'exécution basé sur un interpréteur IL sans aucune prise en charge JIT.

Selon toute vraisemblance, AoT rendra l'application plus grande à télécharger, car .NET IL est un format plus compact que sa représentation compilée nativement. Ainsi, l'utilisation de l'AoT entraînera probablement un compromis entre l'accélération des performances d'exécution au détriment de l'augmentation de la taille du téléchargement. L'idée actuelle est que nous mettrons la chaîne d'outils AoT à la disposition des développeurs afin que vous puissiez décider quelle quantité de votre application vous souhaitez utiliser pour l'AoT, puis l'application s'exécutera en mode mixte, où une partie de l'application s'exécute toujours en tant que .NET IL , tandis que les chemins critiques de performances sont précompilés dans WebAssembly.

Pour améliorer les performances de démarrage de l'application, nous envisageons d'autres améliorations de l'éditeur de liens .NET IL et travaillons également sur les bibliothèques de framework de base pour les rendre plus associables. Nous prévoyons également d'examiner les performances de démarrage du runtime lui-même une fois celui-ci téléchargé.

@ danroth27 Y a-t-il des problèmes que je peux suivre concernant la progression des performances de démarrage de l'application ? C'est en ce moment ma plus grande préoccupation au sujet du blazor.

@danroth27 :+1: Merci beaucoup pour l'info, j'utilise principalement Blazor dans les environnements LAN où les temps de téléchargement devraient être presque nuls et je pensais que le navigateur mettait en cache le. Net DLL de toute façon. Mais dans un Startup Issue, je serais également très intéressé.

Veuillez noter que les temps de démarrage pour les applications basées sur WebAssembly comme l'interpréteur Blazor peuvent dépendre du fait que le navigateur met correctement en cache les fichiers. Si le serveur Web hébergeant votre application est mal configuré ou si le fichier a changé ou si le navigateur est incapable de mettre en cache l'application, il devra la recompiler à partir de zéro à chaque démarrage de l'application. Dans des circonstances idéales, le navigateur est capable de le mettre en cache afin que les futures visites après votre première visite démarrent beaucoup plus rapidement.

Vous pouvez voir https://v8.dev/blog/wasm-code-caching pour plus d'informations à ce sujet. Firefox a un mécanisme similaire, et je pense que Safari le fait aussi mais je n'en suis pas sûr.

@ danroth27 J'apprécie vraiment l'explication et la position dans laquelle vous vous trouvez pour essayer de préparer .NET 5 avec tout le reste. Quelques commentaires/questions :

La première étape vers AoT consiste à déplacer Blazor WebAssembly pour utiliser les mêmes bibliothèques .NET de base que celles utilisées par .NET Core, ce qui devrait également améliorer les performances.

Je suppose que vous faites référence au passage à CoreFX à partir de Mono mscorlib? Je pense que c'est une excellente décision si c'est le cas, étant donné les nombreux tests de performance publiés montrant que CoreFX surpasse considérablement Mono (et NetFX d'ailleurs) de manière significative.

Ensuite, nous devons déterminer comment faire en sorte que l'AoT fonctionne bien avec la liaison IL.

Ouais, la liaison a été un obstacle majeur depuis un certain temps maintenant, comme cela a été discuté ici . Pourtant, Uno a réussi à créer une chaîne d'outils et à trouver un équilibre entre interprété et compilé qui peut obtenir des tailles d'applications de l'ordre de 10 Mo ou d'une plage d'adolescents faibles. J'aurais pensé que nous aurions au moins un PoC pour cela du côté de Blazor, juste pour commencer à évaluer les mesures de performance. Ce n'est pas d'avoir la moindre idée du degré d'amélioration des performances qui est le plus préoccupant en ce moment.

Nous prévoyons également d'examiner les performances de démarrage du runtime lui-même une fois celui-ci téléchargé.

La pièce de construction du DOM doit également être examinée attentivement. Le chargement d'une application Blazor vide prend 1 à 2 secondes sur mon bureau et quelques secondes de plus sur mobile. Ayant vécu dans le monde angulaire, je suis habitué à voir "Chargement..." à chaque fois et je trouve que l'heure de démarrage de base est correcte. Le plus gros problème est la vitesse extrêmement lente de la construction de DOM complexes. Même les DOM avec 1 000 à 2 000 éléments ajoutent jusqu'à 5 à 10 secondes pour la charge initiale, et l'interactivité impliquant des éléments complexes ajoute également un décalage important. Je ne vois pas qu'on en parle beaucoup et je crains que (1) AOT ne résolve pas ce problème car il est endémique à l'interopérabilité WASM/JS et à la façon dont les chaînes sont échangées entre les deux ; et (2) le mécanisme de rendu/différentiel dans Blazor est tellement intégré maintenant qu'il est trop tard pour le changer en quelque chose qui serait très performant.

L'idée actuelle est que nous mettrons la chaîne d'outils AoT à la disposition des développeurs afin que vous puissiez décider quelle quantité de votre application vous souhaitez utiliser pour l'AoT, puis l'application s'exécutera en mode mixte,

Exactement comme Uno le fait déjà,...

Voici donc ma réaction et mon analyse à tout cela, et je veux que vous et tout le monde compreniez que j'aborde cela en tant que quelqu'un qui est probablement aussi grand fan de .NET et de Microsoft qu'il ne l'a jamais été. Blazor a été présenté au monde en tant que cadre d'utilisation de _webassembly_ pour ramener .NET dans le navigateur. J'étais en extase quand j'ai appris ça. Mais cela fait plus de deux ans maintenant qu'il a été présenté pour la première fois en avant-première et la pièce d'assemblage Web n'est toujours pas prête pour les applications grand public en raison de graves problèmes de performances. Pendant ce temps, beaucoup de choses ont été investies côté serveur (dont je ne suis toujours pas tout à fait sûr de l'endroit) et maintenant peut-être mobile via Xamarin, mais le WASM peut continuer à être repoussé encore et encore.

.NET a perdu tellement de terrain en tant que plate-forme Web frontale depuis que les SPA ont pris le relais et que Silverlight est mort grâce aux plugins d'interdiction de Chrome. Blazor aurait pu changer tout cela. Mais je ne peux pas dire pour le moment si Blazor WASM est vraiment conçu par Microsoft comme le changeur de jeu stratégique qu'il pourrait être ou simplement une curiosité pour les fanboys comme moi. Mais fanboy ou pas, en tant que propriétaire d'entreprise, si je choisis un framework frontend aujourd'hui pour un nouveau projet ou la reconstruction d'un ancien, comment puis-je justifier auprès de mes contributeurs que Blazor est la voie à suivre, plutôt que React ou Angular ? Quand je liste les avantages et les inconvénients, que me reste-t-il en tant que pro autre que j'aime C# ? Les inconvénients, en revanche, continuent de s'accumuler.

Je suis donc très déçu et un peu démoralisé. Ce n'est pas seulement devoir attendre plus longtemps, c'est qu'il y a encore beaucoup de doutes quant à savoir si cette technologie sera un jour viable, et pour ma part, j'attendais de voir AoT pour pouvoir prendre cette décision.

Je ne m'attends pas à ce que vous changiez votre feuille de route ou que vous soyez vraiment en mesure d'atténuer l'une de ces préoccupations aujourd'hui, mais j'ai pensé qu'elles valaient la peine d'être diffusées. Je veux désespérément que cela réussisse et je n'aimerais rien de plus que .NET reprenne sa place de roi des applications Web interactives. Mais si je devais mettre de l'argent dessus aujourd'hui, ça n'a pas l'air d'être un bon pari. S'il vous plaît, prouvez-moi que j'ai tort !

Je dois dire que je suis dans la même situation que @legistek. J'utilise Blazor depuis la version 0.1 et je suis un grand fan de cette technologie. Bien sûr, pour certains d'entre nous, il est agréable d'avoir une option pour exécuter Blazor sur le serveur. C'est également une option intéressante d'avoir Blazor sur mobile, mais je crois vraiment que la mise en œuvre de WebAssembly devrait avoir la plus haute priorité. C'est le changeur de jeu, c'est l'avenir.

@ danroth27 pour blazor, la vitesse de désérialisation JSON est extrêmement lente pour les grandes listes d'objets, existe-t-il des conseils sur la façon de procéder rapidement plutôt que d'utiliser l'interpréteur actuellement lent.

Je trouve que c'est la pire performance atteinte dans blazor si des API de repos sont utilisées et que les tailles de données sont plus grandes alors que javascript n'est pas affecté par la taille de la même manière.

Si cela nécessite un processus de désérialisation manuel, cela conviendrait pour ces listes plus importantes, je me demande simplement s'il existe des conseils à ce sujet. Idéalement, nous serions capables d'AOT les désérialiseurs ?

Pour réduire le temps de démarrage, je suggère un chargement paresseux. Cela signifie uniquement charger les dll qui sont nécessaires pour cette vue ou cette page spécifique. Cela accélérerait effectivement le démarrage

@ram16g @legistek Nous travaillons à améliorer les performances d'exécution de Blazor WebAssembly dans .NET 5 (et au-delà). AoT est toujours sur notre feuille de route à long terme, mais cela prendra plus de temps à livrer que nous n'en avons le temps dans .NET 5. La première étape vers AoT consiste à déplacer Blazor WebAssembly pour utiliser les mêmes bibliothèques .NET de base que celles utilisées par .NET Core, qui devrait également améliorer les performances. C'est le travail qui se fait en ce moment. Ensuite, nous devons déterminer comment faire en sorte que l'AoT fonctionne bien avec la liaison IL. À ce stade, nous pensons qu'il nous faudra jusqu'au premier trimestre de l'année prochaine (premières prévisualisations de .NET 6) pour rendre publiques les premières prévisualisations de la prise en charge de .NET AoT pour WebAssembly. Mais même sans AoT, nous nous attendons toujours à apporter des améliorations de performances significatives pour Blazor WebAssembly dans .NET 5.

Bonjour à tous et @danroth27 , dans quelle mesure cela améliorera-t-il la vitesse de démarrage (en supposant que tous les éléments soient mis en cache) ? Que puis-je faire pour aider à livrer d'ici novembre ? Je n'aime plus utiliser angulaire. ahahahaha, je suis prêt à offrir un codage gratuit juste pour accélérer cela. Je ne me soucie pas vraiment de la taille du téléchargement initial car il sera simplement mis en cache. Les utilisateurs sont des visiteurs fréquents. angular peut démarrer instantanément lorsque les fichiers sont mis en cache.

@hoksource Nous n'avons pas de chiffres exacts sur la façon dont les caractéristiques de performances vont changer, mais si vous essayez les aperçus dans 1 à 2 mois, vous devriez pouvoir le découvrir.

@hoksource Nous n'avons pas de chiffres exacts sur la façon dont les caractéristiques de performances vont changer, mais si vous essayez les aperçus dans 1 à 2 mois, vous devriez pouvoir le découvrir.

@SteveSandersonMS ok alors
pour contribuer mon objectif sera de pouvoir faire ce qui suit :

Option 1 : Approche directe (traiter le problème directement) :
[ ] apprendre à compiler un projet mono
[ ] apprendre à compiler le projet asp.net blazor
[ ] apprendre à compiler un blazor asp.net avec webassembly
[ ] apprenez à compiler complètement le programme client blazor en webassembly (est-ce que mono->webassembly n'est pas fait ? peut-il combiner tous les binaires de référence dans 1 fichier wasm ?)
[ ] vérifie si mono peut compiler tout un projet d'assemblage Web sur un assemblage Web.
[ ] découvrir comment prendre en charge tous les langages c#/.net manquants dans l'assemblage Web
[ ] déterminer la structure de liaison optimale pour convertir toutes les dll en 1 wasm ou plusieurs fichiers wasm
[ ] trouver la meilleure façon de faire au-dessus de la taille du fichier et des performances de pesée
[ ] apprendre/concevoir lier et fusionner des binaires à 1 webassembly ou autoriser le lazyload avec des assemblys partiels
[ ] ont différents ensembles de solutions, choisissez les meilleures solutions, présentez-les à vous les gars. via une branche de référentiel public/privé du projet en cours

Option 2 : (traiter le problème indirectement)
[ ] Je vais faire de petites tâches simples comme des modules/conception/documentations petits/faciles, j'ai confiance que de plus grands ingénieurs/concepteurs peuvent concentrer/diriger leurs ressources sur l'approche directe indiquée sur l'option 1 avant la version nov.net 5.

• question supplémentaire. toutes les bibliothèques de référence sont-elles censées être open source ? J'ai codé pas mal de bibliothèques, mais je ne sais pas si je veux toutes les exposer publiquement.

Mais je pense que l'option 1 serait la meilleure option car je ne referais pas d'autres choses que l'un de vous fait. Veuillez confirmer si j'ai raté quelque chose.

@hoksource Merci pour votre volonté de vous impliquer. Actuellement, la seule option pratique est l'option 1, car l'équipe ASP.NET Core est entièrement occupée par d'autres travaux. Je sais que c'est un grand nombre de choses que vous auriez à comprendre, mais j'espère que cela aide à expliquer pourquoi ce n'est pas quelque chose que nous pouvons simplement glisser dans le jalon .NET 5 :) Il semble que vous ayez de bonnes idées dans la gamme des choses nécessaires ici.

question supplémentaire. toutes les bibliothèques de référence sont-elles censées être open source ? J'ai codé pas mal de bibliothèques, mais je ne sais pas si je veux toutes les exposer publiquement.

C'est entièrement à vous de décider ce que vous faites open source et ce que vous ne faites pas. ASP.NET Core lui-même est open source, mais vous pouvez créer des éléments à source fermée par-dessus si vous le souhaitez. Nous ne pouvons inclure que des éléments open source dans notre référentiel ici.

Pour les environnements d'exécution basés sur JIT, AoT peut améliorer les performances de démarrage car vous évitez le besoin de JIT au moment de l'exécution, mais Blazor WebAssembly utilise un environnement d'exécution basé sur un interpréteur IL sans aucune prise en charge JIT.

Par curiosité : le JITting sur le client serait-il une alternative pratique à l'interprétation/au plein AoT ?

Salut les gens! Je viens de parler avec certaines équipes et des choses. Il semble que cela soit à peu près essentiel pour les bibliothèques telles que SkiaSharp. La partie principale de SkiaSharp est une bibliothèque native et la sortie est essentiellement un fichier .a qui doit être lié de manière statique.

Pour info, il est actuellement possible de lier statiquement une bibliothèque native au runtime. Ce n'est pas quelque chose que je recommanderais car ce n'est pas trivial, mais vous pouvez le faire, puis p/invoquer dans la bibliothèque liée de manière statique une fois que toutes les pièces sont là. Je ne sais pas si nous avons encore des cas de test qui le font, donc cela peut nécessiter une infrastructure supplémentaire qui n'est pas encore disponible dans Blazor. Vous devrez compiler votre propre dotnet.wasm/dotnet.js pour l'intégrer à vos versions Blazor, ce qui n'est pas pour les âmes sensibles.

Les bibliothèques natives dynamiques sont une autre affaire, je crois comprendre que l'outillage pour cela dans wasm en général n'est pas génial en ce moment, avant même de se demander si Blazor les prend en charge.

J'ai découvert l'année dernière que la liaison dynamique n'est pas du tout une solution viable à ce stade. Emscripten implique que le module wasm "principal" inclut toutes les combinaisons possibles de bibliothèques système que toute bibliothèque dynamique aimerait utiliser. Cela donne un très gros module wasm commun pour commencer.

J'ai essayé d'utiliser cette approche avec Uno.SkiaSharp pendant un moment, mais c'était dur et j'ai mis ça de côté (à ce moment-là, @vargaz s'est probablement abstenu de dire "je te l'avais dit" ).

Le programme d'amorçage Uno est désormais capable d'utiliser la liaison statique (directions ici ) et P/Invoke via WSL sous Windows, et comme il utilise les mêmes chemins d'exécution que l'interop interne System.Native, il est maintenant assez stable. Vous pouvez même facilement interopérer avec des modules de rouille de cette façon.

J'ai fait quelques lectures, seul le runtime .net est converti en wasm. Toutes les dll sont téléchargées et analysées au démarrage. il semble que le runtime wasm utilisé soit mono. Leur objectif est maintenant d'utiliser à la place le runtime de base .net.

Le compilateur aot complet actuel est fait par mono, mais je ne sais pas si un aot complet avec le noyau .net devrait être le chemin/chemin. (Aucune idée de ce que je dis ici. a besoin d'un expert)

Internet dit que le noyau .net s'exécute deux fois plus vite que mono pour les tâches de calcul intensif. Le démarrage est lié à io, en téléchargeant d'abord les binaires et les dépendances .dll. (Plusieurs fichiers) en les analysant en mémoire. Ensuite, démarrez l'application cliente blazor wasm par-dessus. Le téléchargement prend un certain temps (mais peut être mis en cache) et l'analyse prend un certain temps. Le compilateur aot ne sait pas non plus quelles sont les dépendances de blazor et lesquelles sont spécifiques à l'application. Ce sera compliqué si vous définissez toujours la dll à inclure dans aot wasm. Donc, un aot complet a l'air bien. (Mais ce sera plus rapide avec la mise en œuvre du runtime .net core au lieu de mono? Je ne suis pas sûr à nouveau de celui-ci) je ne sais pas non plus si la conception / la mise en œuvre de la compilation complète aot wasm se fait avec le runtime mono ou .net. Pas sûr non plus de l'avancement

@danroth27 Y a-t-il des progrès ?

Sera-t-il disponible en .NET 5 ?
Ce serait bien d'avoir une pré-version pour vérifier cette fonctionnalité aussi ;)

@redradist AOT ne sera pas mis en place par .NET 5. Ils font de l'optimisation sur blazor wasm. Mais d'après ce que j'ai lu, ils font l'assemblage et le rognage sur le terrain. et des optimisations d'exécution. J'espère qu'ils pourront obtenir le démarrage <1 lorsqu'ils seront mis en cache sur les téléphones mobiles. commentaire de danroth27

@hoksource

@redradist AOT ne sera pas mis en place par .NET 5. Ils font de l'optimisation sur blazor wasm. Mais d'après ce que j'ai lu, ils font l'assemblage et le rognage sur le terrain. et des optimisations d'exécution. J'espère qu'ils pourront obtenir le démarrage <1 lorsqu'ils seront mis en cache sur les téléphones mobiles. commentaire de danroth27

C'est triste :(

J'ai une question. Avec Blazor AOT travaillez-vous sur :

1. compilation de C# directement au format de bytecode WebAssembly
2. ou travaillez-vous sur la transformation de l'IL compilé dans les DLL .NET au format de bytecode WebAssembly

L'approche 2) préserverait tous les outils .NET (y compris les nôtres) qui reposent sur l'IL standard et les métadonnées compilées ainsi que sur la PDB pour fonctionner. De plus 2) aurait l'avantage supplémentaire d'avoir System DLLs également compilé à WebAssembly, peut - être avec le code non exécuté lors de l' exécution élagué (voir le Mono.Linker projet par @JbEvain).
Merci

D'ailleurs, il existe de nombreuses ressources sur Blazor, mais je n'ai pas trouvé celle avec la bonne granularité pour me renseigner sur Blazor Internals, alors je l'ai écrite.

2 pas 1

De plus, j'espère que le processus AoT générera des cartes de source appropriées (de wasm à C#) pour faciliter le débogage.

J'espère voir ce support au premier trimestre 2021 pour les versions préliminaires de .Net 6. Ceci est fondamental pour prendre en charge les référentiels tels que SkiaSharp s'exécutant de manière native dans le navigateur Web.

Merci de nous avoir contacté.
Nous déplaçons ce problème vers le jalon Next sprint planning pour une évaluation/une considération future. Nous évaluerons la demande lorsque nous planifierons les travaux pour la prochaine étape. Pour en savoir plus sur ce à quoi vous attendre ensuite et comment ce problème sera traité, vous pouvez en savoir plus sur notre processus de tri ici .