Aspnetcore: Compilación AoT

Seguimiento del estado de mono-wasm

¿Conoce algún problema en el que podamos hacer un seguimiento del progreso en esto?

El modo de intérprete actual es muy lento.
https://dotnetfiddle.net/JUpsRT

.NET 300 ms
WASM: 13155 ms

Sí, creemos que esto se debe más a que no se ha optimizado nada todavía que a una indicación de que deberíamos pasar a AoT en este momento, pero sabremos más a medida que el intérprete de IL y el soporte de AoT maduren.

@ danroth27 Por lo que puedo decir, la diferencia de rendimiento entre el intérprete Mono IL y la versión actual de mono.wasm es de aproximadamente 5-10x. En general, mono.wasm es aproximadamente 50-80x y el intérprete de IL aproximadamente 10 veces más lento que una aplicación de consola nativa .NET Core.

Por lo tanto, el intérprete todavía no es muy rápido en general y WebAssembly agrega aún más gastos generales además de eso.

Asumiría que AOT probablemente todavía tiene más posibilidades de acelerar las cosas, pero tiene razón en que es muy probable que sea demasiado pronto para descartar al intérprete, ya que la mayoría de las aplicaciones web ni siquiera tienen demandas de rendimiento tan altas y lo más probable es que estén bien. con una versión interpretada.

El hecho de que AOT sea más eficiente no solo es importante para las aplicaciones intensivas. También es importante para los dispositivos móviles y otras plataformas de gama baja, especialmente cuando se considera el uso de la batería.

¿Existe actualmente alguna forma viable de habilitar la compilación AoT para proyectos Blazor? Sigo leyendo publicaciones de blog que afirman que Blazor ya tiene un modo AoT; Si esto es cierto, ¿podría alguien señalar un artículo que explique cómo habilitarlo?

@TheFanatr la compilación de AOT depende de que mono admita esta función. Por lo que puedo decir, la última actualización sobre el tema fue de @migueldeicaza en Blazor Gitter .

Miguel de Icaza (08/06/2018 19:01):
Estamos trabajando en ello. Lo que pasó es esto:
El intérprete está usando "emscripten" que tiene una biblioteca bastante completa en la que podemos confiar. Y nuestro motor AOT se construyó en LLVM puro, lo que requiere que escribamos la biblioteca completa. Este último es el lugar ideal, porque obtenemos enlazadores nativos y soporte llvm inmediato, etc. Pero nos enviaría por el camino de tener que escribir esa libc.
Entonces, a corto plazo, nos estamos moviendo para emscripten el compilador AOT, asegúrese de mantener la compatibilidad. Sin embargo, la desventaja es que las herramientas emscripten son más antiguas, por lo que muchas de las mejores piezas como el enlazador LLVM no están disponibles. Así que estamos trabajando en esas cosas.
Básicamente, teníamos algo hecho, pero tuvimos que empezar de cero para trabajar con lo que tenemos sin obligarnos a escribir y emular todo por nuestra cuenta. Podríamos haber intentado combinar esos dos, pero eso también es un gran esfuerzo. Así que creemos que podemos hacer emscripten por ahora a través de algunos trucos ingeniosos aquí y allá.

En resumen, están trabajando en ello, pero no hay una buena opción para hacerlo con las compilaciones públicas actuales.

¡¡Se ha informado de un gran progreso en CoreRT !!

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

¿Alguien tiene una idea de lo que está bloqueando esto? Podría estar dispuesto a invertir algunos billones de horas-hombre para ver que AOT ocurra más temprano que tarde, ahora que los poderes que están en Microsoft se han comprometido con el blazor del lado del cliente. AOT será realmente importante si queremos desarrollar (excelentes) PWA con Blazor.

@honkmother AoT está siendo trabajado por la gente de mono.wasm en el repositorio https://github.com/mono/mono . ¡Estoy seguro de que estarán encantados de contar con tu ayuda! Este problema rastrea el consumo de su trabajo una vez que está listo.

Creo que tengo una pregunta algo relacionada, pero no está bien pensada y mal redactada: he estado experimentando con ILRepack y Blazor, y logré empaquetar la mayoría de las DLL juntas en una sola gota monolítica. ¿Tienen la intención de empaquetar en algún momento las bibliotecas comunes como una sola dll?

@honkmother Actualmente no tenemos ningún plan concreto para hacerlo, pero nos interesaría conocer los resultados de su experimentación.

Pude fusionar la mayoría de ellos con solo usar ILRepack en / dist / bin / output, e incluir System.Core.dll. Los tiempos de inicio se mejoraron después de combinar la mayoría de las bibliotecas, pero introdujo muchos errores que me rascaban la cabeza y no tengo ni idea de cómo resolverlos; y, por supuesto, está perdiendo la capacidad de confiar en el almacenamiento en caché para obtener piezas de código actualizadas sin tener que descargar todo el blob nuevamente.

Entonces, ¿ha habido alguna novedad sobre esto o al menos una ETA? El lado del servidor funciona bastante bien, pero el rendimiento de WASM del lado del cliente a través del intérprete sigue siendo inaceptable tan pronto como el DOM se vuelve razonablemente complejo.

No lo creo, el AOT en el repositorio mono todavía parece ser un WIP; Escuché que lo tendremos para el primer trimestre de 2020, pero no sé si eso es seguro; lo cual es triste porque tengo una PWA muy buena configurada con el lado del cliente, pero tiene algunos problemas de rendimiento que AOT probablemente aliviaría sin necesidad de trucos sucios.

Mientras tanto, hay algunas cosas que puede hacer para aliviar el dolor allí, es decir, usar DOM virtual y / o usar RenderTreeBuilder directamente para que no esté renderizando todo a la vez y tenga cierto control sobre lo que está sucediendo.

Bueno, también me preguntaba si algo ha cambiado a la luz del anuncio de hace unos meses sobre .NET 5 . Cita interesante allí:

El proyecto Blazor ya está utilizando Mono AOT. Será uno de los primeros proyectos en hacer la transición a .NET 5. Lo estamos usando como uno de los escenarios para probar este plan.

¿Saben algo que nosotros no?

Mientras tanto, hay algunas cosas que puede hacer para aliviar el dolor allí, es decir, usar DOM virtual y / o usar RenderTreeBuilder directamente para que no esté renderizando todo a la vez y tenga cierto control sobre lo que está sucediendo.

En efecto. Estoy creando un marco MVVM desde cero inspirado en WPF y una de las primeras cosas que hago es anular ShouldRender para desactivar los activadores de renderizado automático de Blazor y, en su lugar, confiar en los cambios de propiedad para indicar a los componentes cuándo volver a renderizar. De hecho, una mejora en el rendimiento de HUUUUGGGE proviene de la actualización de estilos a través de la interoperabilidad JS, en lugar de StateHasChanged , siempre que sea posible.

No obstante, tengo problemas cuando es necesario generar DOM grandes por adelantado, por ejemplo, una lista compleja o una cuadrícula de datos. El lado del servidor está bien, pero el lado del cliente tarda de 5 a 10 segundos a veces solo para renderizar inicialmente.

Lo que realmente necesitamos es un VirtualizingPanel como en WPF. He estado pensando mucho en cómo se podría implementar esto en la interoperabilidad de Blazor y JS, pero aún se me escapa una solución completa. En WPF funciona porque el marco es responsable de medir cada elemento visual y reportar su tamaño. Incluso con la interoperabilidad de JS, no estoy seguro de que sea posible lo mismo, y todavía no he visto una buena solución generalizada para esto en ningún marco web.

SyncFusion tiene algunos componentes de virtualización, a saber, una vista de lista; no tengo idea de cómo funcionan, pero los estoy usando. Tal vez quiera verlos.

También hay https://github.com/SamProf/BlazorVirtualScrolling que también vale la pena ver.

Oh, sí, lo vi. Me alegra saber que le funciona bien. Tiene las limitaciones importantes de necesitar una altura uniforme del artículo y que la altura se conozca de antemano. Pero esa podría ser una solución provisional.

¿Alguien puede etiquetar este problema con la etiqueta blazor-wasm? Es difícil encontrar este problema en medio de todos los problemas de Blazor del lado del servidor (o del alojamiento independiente).

Y para aquellos que buscan una descripción general del trabajo de Mono WASM AOT que se está realizando, encontré este enlace:
https://github.com/mono/mono/projects/11

Tu deseo es mi comando 😆

¡Gracias, eso es muy útil!

¿Es posible obtener incluso las estimaciones más vagas de cuándo podríamos comenzar a usar WASM compilado por AOT con Blazor, incluso de manera experimental? ¿6 meses? ¿Un año? ¿Alguien en el equipo de Blazor ha logrado que funcione con éxito, incluso de una manera ad-hoc?

Es un poco arriesgado comenzar a invertir mucho tiempo en Blazor del lado del cliente, o planificarlo, cuando todavía no sabemos realmente cómo será el producto final. Por muy bueno que sea el lado del servidor, realmente necesitamos una versión del lado del cliente confiable y eficiente para que esto sea viable.

He publicado esta pregunta aquí https://github.com/mono/mono/issues/10222 pero obtuve la respuesta de que es un lugar equivocado. Volviendo a publicar aquí:

Se anunció que Blazor WASM se lanzará en mayo de 2020. ¿Podemos asumir que será una aplicación WASM nativa en este momento? ¿Cuál es la respuesta correcta?

1. Si.
2. Lo intentaremos, pero no estamos seguros.
3. No, estará disponible en noviembre de 2020 con .NET 5.0.
4. No, y todavía no tenemos una hoja de ruta.

Para todos los fanáticos de Blazor, dos cosas son muy importantes:

• Velocidad en tiempo de ejecución: el intérprete es demasiado lento en algunos casos de uso.
• Tamaño de descarga: con suerte, podrá lograr un tamaño de WASM similar al de las DLL de .NET actuales y podremos eliminar mono.wasm por completo (creo que este archivo solo contiene un intérprete de IL, ¿verdad?).

Soy un gran fan de Blazor desde el principio. Sé que el lado del servidor Blazor tiene algunas ventajas para algunas personas, pero todos estamos esperando una revolución real: Blazor rápido y confiable en el navegador.

¡Gracias a todos por su arduo trabajo!

@ Andrzej-W Esto podría ser un poco engañoso para cualquiera que lo lea y asuma que noviembre de 2020 es el lanzamiento canónico.

Personalmente, he oído que se supone que saldrá oficialmente alrededor del primer trimestre de 2020.

Siendo realistas, no hay nada que nos impida implementarlo en nuestros procesos de compilación en este momento, hasta donde yo sé, más allá del tamaño del ejecutable inflado y el hecho de que Microsoft aún no lo admite.

Siendo realistas, no hay nada que nos impida implementarlo en nuestros procesos de compilación en este momento, hasta donde yo sé, más allá del tamaño del ejecutable inflado y el hecho de que Microsoft aún no lo admite.

¿Alguien ha probado esto? Creo que es importante para nosotros tener al menos una prueba de concepto para que podamos ver cómo funciona en comparación con el interpretado y en el lado del servidor. Sé que el tamaño de exe es algo en lo que está trabajando el equipo mono, y es importante, pero la velocidad de la aplicación es lo más importante. (Y el tiempo de compilación es realmente irrelevante en mi humilde opinión porque haremos la depuración del lado del servidor y solo compilaremos en WASM nativo para su lanzamiento. El tiempo de compilación para el paquete web también puede ser bastante atroz).

En .NET Conf anunciamos que la primera versión de Blazor WebAssembly está prevista para mayo de 2020. Para esta primera versión de Blazor WebAssembly, esperamos que el tiempo de ejecución siga basándose en el intérprete de IL que estamos utilizando actualmente.

El equipo de tiempo de ejecución de .NET está trabajando con anticipación en el soporte de compilación para compilar directamente en WASM. Este enfoque tiene la ventaja de mejorar el rendimiento en tiempo de ejecución, pero a expensas del tamaño de la aplicación.

Para el lanzamiento inicial de Blazor WebAssembly en mayo, estamos explorando la ejecución del intérprete de IL en un modo mixto, donde las rutas activas se han compilado en WASM pero el resto de la aplicación son ensamblados .NET. Esto proporciona un buen compromiso entre el rendimiento en tiempo de ejecución y el tamaño de la aplicación. Sin embargo, aún no está claro si llegará a tiempo para mayo.

A largo plazo, queremos proporcionar un SDK que le dé al desarrollador de la aplicación el control de qué partes de su aplicación se compilan directamente en WASM. Todavía no hay una hoja de ruta sobre cuándo estará disponible dicho SDK.

@lewing @richlander

Gracias @ danroth27 por la explicación. El tamaño de la descarga se puede enmascarar parcialmente mediante la representación previa del lado del servidor; asegúrese de que https://github.com/danroth27/ClientSideBlazorWithPrerendering funcionará en todas las versiones futuras de Blazor (pre).

@ danroth27 ¡ gracias por la actualización! Una pregunta aclaratoria: ¿"el equipo en tiempo de ejecución de .NET" se refiere al equipo Mono, CoreRT, .NET 5 u otra cosa?

@legistek Ahora son todos un equipo: sonríe :

Oh, cierto, lo olvidé. ; D A lo que me refería era a si

@legistek Sí, todo el trabajo de .NET WASM está sucediendo actualmente en el repositorio mono.

He creado una aplicación bastante compleja que ejecuta Blazor del lado del servidor ahora, y está funcionando muy bien. (Sin embargo, WASM a través del intérprete de IL es tan lento que resulta inutilizable).

Realmente me muero por saber cómo funcionaría con WASM compilado.

Si ignoramos el tamaño de descarga o el tiempo de compilación solo por el momento, ¿hay alguna forma de que AOT compile una aplicación Blazor para WASM y la pruebe? En el repositorio mono (https://github.com/mono/mono/issues/10222) la gente está publicando algunos ejemplos de AOT con otras plataformas como Uno, pero todavía no he visto un ejemplo de Blazor y mucho menos instrucciones sobre cómo para hacerlo.

Me doy cuenta de que el proceso de construcción sería completamente ad hoc en este punto, pero ¿es posible incluso en principio solo para que podamos tener una idea aproximada de la diferencia de rendimiento? Me gusta el lado del servidor para depurar y hacer demostraciones, pero no sé si es viable para una implementación de producción a escala. Por lo tanto, dudo en trabajar mucho más en este proyecto hasta que sepa que el rendimiento en AOT WASM será bueno. Me imagino que hay mucha gente en el mismo barco.

Solo para continuar, terminé probando el bootstrap Uno WASM usando WSL (descrito aquí ) y realmente funciona bastante bien. Este problema aquí todavía está marcado como BLOQUEADO y, aunque sé que todavía están trabajando para reducir el tamaño de la carga útil, no parece que deba bloquear el trabajo en una cadena de compilación AOT para Blazor, incluso si es solo Linux por ahora. ¿Está sucediendo eso y, si no, qué está esperando el equipo Blazor del equipo Mono antes de comenzar eso?

@legistek, ¿

Creé un subconjunto de mi aplicación y luego simplemente ejecuté algunas métricas de rendimiento, ya que no podía ejecutar todo sin el arranque de Blazor.

Para matemáticas (generación de números aleatorios y aritmética simple) encontré que AOT es aproximadamente 40 veces más rápido de lo que se interpreta.

Lo que realmente me interesaba eran cosas que sabía que serían ineficaces como la reflexión y la manipulación de cuerdas. Mi aplicación tiene un marco de enlace de datos personalizado similar a WPF, así que intenté configurar un enlace de datos complejo y cambiar el valor a una cadena aleatoria 10,000 veces. Aquí estaban los resultados:

Monointerpretado IL: 2,49 s
AOT completo (cromo): 0,702 s
AOT completo (Firefox): 0,5 s
Nativo: 0.067 s

Básicamente, tenemos el peor de los casos en el que AOT es aproximadamente 4 veces más rápido que el IL interpretado, pero en el mejor de los casos es de hasta 40 veces.

Creo que probablemente sea de esperar.

Desafortunadamente, esto todavía no nos dice qué tan bien funcionará Blazor AOT en comparación con la interpretación, pero soy un poco pesimista de que va a estar en el lado inferior (4-5x) porque se presume que Blazor está haciendo mucha manipulación de cadenas para construir el DOM, y también un SPA sofisticado, realizarán muchas llamadas a la API JSON (que, por supuesto, utilizan la reflexión y las cadenas de forma extensiva). Pero realmente no podemos estar seguros hasta que podamos probar una aplicación Blazor real con AOT.

Me imagino que el rendimiento mejorará notablemente en un futuro cercano a medida que los proveedores de navegadores comiencen a tomar WebAssembly más en serio.

Creo que AOT merece mucha más investigación más temprano que tarde porque Blazor probablemente vivirá o morirá por la reputación de su implementación del lado del cliente en WASM.

Proyectos como https://d07riv.github.io/diabloweb/ demuestran sin lugar a dudas que WebAssembly es más que capaz de manejarse solo, pero todavía tengo que ver una prueba de concepto igualmente impresionante que se ejecute en Mono + WASM.

Este tema está abierto desde hace dos años. ¿Hay algún avance?

@partyelite Sí, ha habido avances. Existe una implementación de la compilación AoT para WASM en el repositorio https://github.com/mono/mono y el tiempo de ejecución se ha actualizado para admitir la ejecución de una combinación de .NET IL y archivos WASM compilados. Sin embargo, el soporte de AoT no estará listo para el próximo lanzamiento de mayo. Revisaremos el envío para .NET 5.

Probé la opción de compilación AOT a la que se refiere Dan y funciona bien con Uno.

Lo que todavía me estoy rascando la cabeza es por qué todavía no hay al menos un PoC funcionando con Blazor. Me doy cuenta de que la cadena de herramientas sigue siendo Linux y los archivos de salida son mucho más grandes de lo que queremos, pero ¿qué impide hacer un ejemplo de una aplicación Blazor que funcione con AoT para que podamos medir el rendimiento y la viabilidad?

No estoy seguro de si esto está relacionado, pero en el repositorio de Syncfusion se informó un problema de rendimiento hace un tiempo (https://github.com/syncfusion/blazor-samples/issues/50), que se dice que se debe a el rendimiento lento de mono.

En mi análisis, el problema de rendimiento se desglosa hasta llamar a js_to_wasm :

¿Es esto algo que será resuelto por este y el equipo mono? ¿O es esto algo ajeno?

@Herdo podría estar relacionado con esto: https://github.com/dotnet/aspnetcore/issues/5617

Verifique el registro de su consola web para ver si está generando GC en exceso. Esto parece estar integrado en el tiempo de ejecución de WASM Mono y debe ser configurable en mi opinión.

@honkmother ,
¿Puede compartir más información sobre cómo logró empaquetar archivos DLL de Blazor con ILRepack? Usé ILRepack.MSBuild.Task como se detalla aquí . El empaque se realiza correctamente, pero cuando ejecuto la aplicación siempre aparece este error:

WASM: System.IO.FileNotFoundException: no se pudo cargar el archivo o ensamblado 'netstandard, Version = 2.1.0.0, Culture = neutral, PublicKeyToken = cc7b13ffcd2ddd51' o una de sus dependencias.

Parece que el empaquetado rompe algo, o en la lista impide un arranque correcto de la aplicación.

hmm AOT está en UNO . ¿Puede C&P esta solución?

¿.Net 5 no es compatible con la compilación AoT para Blazor?

También está tachado de la hoja de ruta.

Me gustaría escuchar un comentario oficial antes de sacar conclusiones precipitadas, pero si es cierto, esta es una muy mala noticia que no solo afecta a Blazor, sino que me obligaría a reevaluar .NET en sí mismo como una plataforma frontend.

Tampoco se ha informado de actividad en meses en el lado Mono de esto:
https://github.com/mono/mono/issues/10222

Tal vez sea hora de reducir las pérdidas y centrarse en CoreRT en su lugar.

@ ram16g @legistek Estamos trabajando para mejorar el rendimiento del tiempo de ejecución de Blazor WebAssembly en .NET 5 (y más allá). AoT todavía está en nuestra hoja de ruta a largo plazo, pero tardará más en entregarse de lo que tenemos tiempo en .NET 5. El primer paso para AoT es mover Blazor WebAssembly para usar las mismas bibliotecas .NET centrales que utilizan .NET Core, que también debería ayudar al rendimiento. Ese es el trabajo que está sucediendo en este momento. Luego tenemos que averiguar cómo hacer que AoT funcione bien con enlaces IL. En este punto, creemos que necesitaremos hasta el primer trimestre del próximo año (primeras vistas previas de .NET 6) para que las primeras vistas previas del soporte de .NET AoT para WebAssembly estén disponibles públicamente. Pero incluso sin AoT, todavía esperamos ofrecer mejoras de rendimiento significativas para Blazor WebAssembly en .NET 5.

Hola @ danroth27 , el rendimiento general en este momento no me preocupa tanto, pero ¿qué pasa con el rendimiento de inicio inicial? Se necesitan de 2 a 3 segundos en cada visita a la página hasta que se cargue la página real, hasta que se cargue el tiempo de ejecución, las DLL compiladas, etc. ¿Habrá mejoras sin AOT? ¿O tenemos que confiar en la reproducción previa?

Hola @MichaelPeter. El tiempo de carga inicial de la página se domina descargando la aplicación e iniciando el tiempo de ejecución. AoT realmente no ayudará a eso. El objetivo de AoT es mejorar el rendimiento en tiempo de ejecución, no reducir el tamaño de descarga de la aplicación. Para los tiempos de ejecución basados ​​en JIT, AoT puede mejorar el rendimiento de inicio porque evita la necesidad de JIT en tiempo de ejecución, pero Blazor WebAssembly usa un tiempo de ejecución basado en intérprete de IL sin ningún soporte JIT.

Con toda probabilidad, AoT hará que la aplicación sea más grande para descargar, porque .NET IL es un formato más compacto que su representación compilada de forma nativa. Por lo tanto, el uso de AoT probablemente resultará en una compensación entre acelerar el rendimiento del tiempo de ejecución a expensas de un mayor tamaño de descarga. La idea actual es que pondremos la cadena de herramientas de AoT a disposición de los desarrolladores para que pueda decidir qué parte de su aplicación desea AoT y luego la aplicación se ejecutará en un modo mixto, donde parte de la aplicación todavía se ejecuta como .NET IL , mientras que las rutas críticas de rendimiento están precompiladas en WebAssembly.

Para mejorar el rendimiento inicial de la aplicación, estamos buscando mejoras adicionales en el vinculador .NET IL y también trabajando en las bibliotecas del marco central para hacerlas más vinculables. También planeamos observar el rendimiento de inicio del tiempo de ejecución en sí una vez que se descargue.

@ danroth27 ¿Hay algún problema que pueda seguir sobre el progreso en el rendimiento de inicio de la aplicación? Esta es en este momento mi mayor preocupación sobre blazor.

@ danroth27 : +1: Muchas gracias por la información, principalmente uso Blazor en envíos LAN donde los tiempos de descarga deberían ser casi cero y pensé que el navegador está almacenando en caché el. Net DLL de todos modos. Pero en un tema de inicio también estaría muy interesado.

Tenga en cuenta que los tiempos de inicio de las aplicaciones basadas en WebAssembly, como el intérprete Blazor, pueden depender de si el navegador almacena correctamente los archivos en caché. Si el servidor web que aloja su aplicación está configurado incorrectamente o el archivo ha cambiado o el navegador no puede almacenar la aplicación en caché, tendrá que volver a compilarla desde cero cada vez que inicie la aplicación. En circunstancias ideales, el navegador puede almacenarlo en caché, por lo que las futuras visitas después de su primera visita comenzarán mucho más rápido.

Puede consultar https://v8.dev/blog/wasm-code-caching para obtener información sobre esto. Firefox tiene un mecanismo similar, y creo que Safari también lo tiene, pero no estoy seguro.

@ danroth27 Realmente aprecio la explicación y la posición en la que se encuentra tratando de preparar .NET 5 junto con todo lo demás. Algunos comentarios / preguntas:

El primer paso para AoT es mover Blazor WebAssembly para usar las mismas bibliotecas .NET centrales que usa .NET Core, lo que también debería ayudar al rendimiento

Supongo que te refieres a cambiar a CoreFX desde Mono mscorlib. Creo que es un movimiento excelente si es así, dados los muchos puntos de referencia de rendimiento publicados que muestran que CoreFX supera a Mono (y NetFX para el caso) de manera significativa.

Luego tenemos que averiguar cómo hacer que AoT funcione bien con enlaces IL.

Sí, la vinculación ha sido un obstáculo importante durante un tiempo, como se ha discutido aquí . Aún así, Uno ha logrado hacer una cadena de herramientas y lograr un equilibrio entre interpretado y compilado que puede obtener tamaños de aplicaciones en el rango de ~ 10 MB o bajo rango de adolescentes. Pensé que al menos tendríamos un PoC para esto en el lado de Blazor, solo para comenzar a medir las métricas de rendimiento. No tener idea de qué grado mejorará el rendimiento es lo que más preocupa en este momento.

También planeamos observar el rendimiento de inicio del tiempo de ejecución en sí una vez que se descargue.

La pieza de construcción DOM de esto también debe analizarse cuidadosamente. La carga de una aplicación Blazor vacía lleva de 1 a 2 segundos en mi escritorio y un par más en el móvil. Habiendo vivido en el mundo Angular, estoy acostumbrado a ver "Cargando ..." cada vez y encuentro que el tiempo de inicio base está bien. El mayor problema son las velocidades terriblemente lentas que crean DOMs complejos. Incluso los DOM con 1000-2000 elementos agregan hasta 5-10 segundos para la carga inicial, y la interactividad que involucra elementos complejos también agrega un retraso significativo. No veo que se hable mucho de esto y me preocupa que (1) AOT no vaya a resolver esto porque es endémico para la interoperabilidad WASM / JS y la forma en que se intercambian cadenas entre los dos; y (2) el mecanismo de renderización / diferenciación en Blazor está tan integrado ahora que es demasiado tarde para convertirlo en algo de alto rendimiento.

La idea actual es que pondremos la cadena de herramientas de AoT a disposición de los desarrolladores para que pueda decidir cuánto de su aplicación desea AoT y luego la aplicación se ejecutará en un modo mixto.

Exactamente como Uno ya lo está haciendo, ...

Así que aquí está mi reacción y análisis a todo esto, y quiero que usted y todos los demás entiendan que estoy llegando a esto como alguien que probablemente sea tan fanático de .NET y Microsoft como nunca lo ha sido. Blazor se presentó al mundo como un marco para usar _webassembly_ para devolver .NET al navegador. Estaba extasiado cuando me enteré. Pero han pasado más de dos años desde que se presentó por primera vez para la vista previa y la pieza de ensamblaje web aún no está lista para aplicaciones de consumo debido a los graves problemas de rendimiento. Mientras tanto, se invirtió mucho en el lado del servidor (cuyo lugar todavía no estoy del todo seguro) y ahora tal vez en dispositivos móviles a través de Xamarin, pero la lata de WASM sigue siendo pateada una y otra vez.

.NET ha perdido mucho terreno como plataforma web frontend desde que los SPA se hicieron cargo y Silverlight murió gracias a los complementos de prohibición de Chrome. Blazor podría haber cambiado todo eso. Pero no puedo decir en este momento si Blazor WASM está realmente pensado por Microsoft como el cambio de juego estratégico que podría ser o simplemente una curiosidad para fanboys como yo. Pero fanático o no, como propietario de un negocio, si estoy eligiendo un marco frontend hoy para un nuevo proyecto o una reconstrucción de uno anterior, ¿cómo justifico ante mis patrocinadores que Blazor es el camino a seguir, en lugar de React o Angular? Cuando enumero los pros y los contras, ¿qué me queda como profesional además de que me gusta C #? Los contras, por otro lado, siguen aumentando.

Así que estoy muy decepcionado y un poco desmoralizado. No se trata solo de tener que esperar más, es que todavía hay muchas dudas sobre si esta tecnología alguna vez será viable, y yo había estado esperando ver AoT para poder tomar esa determinación.

No espero que cambien su hoja de ruta o que realmente estén en condiciones de aliviar cualquiera de estas preocupaciones hoy, pero pensé que valía la pena ventilarlas. Quiero desesperadamente que esto tenga éxito y nada me encantaría más que .NET recuperara su lugar como el rey de las aplicaciones web interactivas. Pero si tuviera que poner dinero hoy, no parece una buena apuesta. ¡Por favor demuéstrame que estoy equivocado!

Debo decir que estoy en la misma situación que @legistek. Estoy usando Blazor de la versión 0.1 y soy un gran admirador de esta tecnología. Por supuesto, para algunos de nosotros es bueno tener una opción para ejecutar Blazor en el servidor. También es una opción interesante tener Blazor en dispositivos móviles, pero realmente creo que la implementación de WebAssembly debería tener la máxima prioridad. Es el cambio de juego, es el futuro.

@ danroth27 para blazor, la velocidad de deserialización de JSON es extremadamente lenta para listas de objetos más grandes, ¿hay alguna guía sobre cómo hacer esto rápido en lugar de usar la forma de intérprete actualmente lenta?

Encuentro que este es el peor golpe de rendimiento en blazor si se utilizan apis de descanso y los tamaños de datos son más grandes, mientras que javascript no se ve afectado por el tamaño de la misma manera.

Si requiere un proceso de deserialización manual, estaría bien para esas listas más grandes, solo me pregunto si hay alguna orientación al respecto. ¿Lo ideal sería que pudiéramos AOT los deserializadores?

Para reducir el tiempo de inicio, sugiero una carga diferida. Lo que significa que solo cargue las DLL que sean necesarias para esa vista o página específica. Eso de hecho aceleraría la puesta en marcha

@ ram16g @legistek Estamos trabajando para mejorar el rendimiento del tiempo de ejecución de Blazor WebAssembly en .NET 5 (y más allá). AoT todavía está en nuestra hoja de ruta a largo plazo, pero tardará más en entregarse de lo que tenemos tiempo en .NET 5. El primer paso para AoT es mover Blazor WebAssembly para usar las mismas bibliotecas .NET centrales que utilizan .NET Core, que también debería ayudar al rendimiento. Ese es el trabajo que está sucediendo en este momento. Luego tenemos que averiguar cómo hacer que AoT funcione bien con enlaces IL. En este punto, creemos que necesitaremos hasta el primer trimestre del próximo año (primeras vistas previas de .NET 6) para que las primeras vistas previas del soporte de .NET AoT para WebAssembly estén disponibles públicamente. Pero incluso sin AoT, todavía esperamos ofrecer mejoras de rendimiento significativas para Blazor WebAssembly en .NET 5.

Hola a todos y @ danroth27 , ¿cuánto mejorará esto la velocidad de inicio (suponiendo que todas las cosas estén en caché)? ¿Qué puedo hacer para ayudar a entregar aot antes de noviembre? Ya no me gusta usar angular. ahahahaha Estoy dispuesto a ofrecer codificación gratuita solo para acelerar esto. Realmente no me importa el tamaño de descarga inicial porque simplemente se almacenará en caché. Los usuarios son visitantes frecuentes. angular puede iniciarse instantáneamente cuando los archivos se almacenan en caché.

@hoksource No tenemos cifras exactas sobre cómo cambiarán las características de rendimiento, sin embargo, si prueba las vistas previas en 1-2 meses, debería poder averiguarlo.

@hoksource No tenemos cifras exactas sobre cómo cambiarán las características de rendimiento, sin embargo, si prueba las vistas previas en 1-2 meses, debería poder averiguarlo.

@SteveSandersonMS ok entonces
Para contribuir mi objetivo será poder hacer lo siguiente:

Opción 1: Enfoque directo (abordar el problema directamente):
[] aprende a compilar un proyecto mono
[] aprender a compilar el proyecto asp.net blazor
[] aprende a compilar un blazor asp.net con webassembly
[] aprender a compilar el programa cliente blazor para ensamblar web completamente aot (¿está hecho mono-> ensamblaje web? ¿Puede combinar todos los binarios de referencia en 1 archivo wasm?)
[] compruebe si mono puede compilar un proyecto de ensamblaje web completo para aot ensamblaje web.
[] descubra cómo admitir todos los lenguajes c # /. net que faltan en el ensamblaje web
[] averigüe la estructura de enlace óptima para convertir todos los dll en 1 wasm o en varios archivos wasm
[] descubra la mejor manera de hacerlo antes de sopesar el tamaño y el rendimiento del archivo
[] aprende / diseña cómo vincular y fusionar archivos binarios en un ensamblaje web o permitir la carga diferida con ensamblajes parciales
[] tiene un conjunto diferente de soluciones, elija las mejores y preséntelas a ustedes. a través de alguna rama de repositorio público / privado del proyecto actual

Opción 2: (lidiar con el problema indirectamente)
[] Haré pequeñas tareas simples como pequeños / módulos fáciles / diseño / documentación, tengo fe en que los mejores ingenieros / diseñadores pueden enfocar / dirigir sus recursos en el enfoque directo indicado en la opción 1 antes del lanzamiento de nov .net 5.

• pregunta adicional. ¿Se supone que todas las bibliotecas de referencia son de código abierto? He codificado bastantes bibliotecas, pero no estoy seguro de querer exponerlas todas públicamente.

Pero creo que la opción 1 sería la mejor opción ya que no volvería a hacer algunas otras cosas que uno de ustedes está haciendo. Por favor confirme si me perdí algo.

@hoksource Gracias por su disposición a participar. Actualmente, la única opción práctica es la opción 1, ya que el equipo de ASP.NET Core está completamente ocupado con otros trabajos. Sé que hay una gran cantidad de cosas que tendrías que resolver, pero espero que eso ayude a explicar por qué no es algo que podamos deslizarnos en el hito de .NET 5 :) Parece que tienes buenos conocimientos en la gama de cosas que se necesitan aquí.

pregunta adicional. ¿Se supone que todas las bibliotecas de referencia son de código abierto? He codificado bastantes bibliotecas, pero no estoy seguro de querer exponerlas todas públicamente.

Depende completamente de ti lo que haces de código abierto y lo que no. ASP.NET Core en sí es de código abierto, pero puede crear elementos de código cerrado encima si lo desea. Solo podemos incluir cosas de código abierto en nuestro repositorio aquí.

Para los tiempos de ejecución basados ​​en JIT, AoT puede mejorar el rendimiento de inicio porque evita la necesidad de JIT en tiempo de ejecución, pero Blazor WebAssembly usa un tiempo de ejecución basado en intérprete de IL sin ningún soporte JIT.

Por curiosidad: ¿JIT en el cliente sería una alternativa práctica a interpretar / pasar a la AoT completa?

¡Hola amigos! Solo he estado hablando con algunos equipos y cosas así. Parece que esto es fundamental para bibliotecas como SkiaSharp. La parte principal de SkiaSharp es una biblioteca nativa y la salida es básicamente un archivo .a que debe estar vinculado estáticamente. Podríamos _podríamos_ construir una biblioteca nativa dinámica, pero ¿Blazor incluso lo admite?

Para su información, actualmente es posible vincular estáticamente una biblioteca nativa en el tiempo de ejecución. No es algo que recomendaría, ya que no es trivial, pero puede hacer eso y luego p / invocar a la biblioteca vinculada estáticamente una vez que todas las piezas estén allí. No sé si tenemos casos de prueba que lo hagan todavía, por lo que puede requerir alguna infraestructura adicional que aún no se envía en Blazor. Tendría que compilar su propio dotnet.wasm / dotnet.js para integrarlo con sus compilaciones Blazor, lo cual no es para los débiles de corazón.

Las bibliotecas nativas dinámicas son otro asunto, tengo entendido que las herramientas para eso en wasm en general no son excelentes en este momento, incluso antes de que llegue a la pregunta de si Blazor las admite.

Descubrí el año pasado que la vinculación dinámica no es una solución viable en este momento. Emscripten implica que el módulo wasm "principal" incluye todas las combinaciones posibles de bibliotecas del sistema que cualquier biblioteca dinámica le gustaría usar. Esto lo convierte en un módulo wasm común muy grande para empezar.

Intenté usar ese enfoque con Uno.SkiaSharp por un tiempo, pero fue difícil y lo dejé de lado (en ese momento

El bootstrapper Uno ahora puede usar enlaces estáticos (instrucciones aquí ) y P / Invoke a través de WSL en Windows, y dado que está usando las mismas rutas de ejecución que usa la interoperabilidad interna System.Native, ahora es bastante estable. Incluso puede interoperar fácilmente con módulos rust de esa manera.

Leí un poco, solo el tiempo de ejecución de .net se convierte a wasm. Todas las DLL se descargan y analizan al inicio. parece que el tiempo de ejecución de wasm que se está utilizando es mono. Su objetivo ahora es utilizar .net core runtime en su lugar.

El compilador de aot completo actual lo está haciendo mono, pero no estoy seguro de si un aot completo con .net core debería ser la ruta / camino. (No tengo idea de lo que estoy diciendo aquí. Necesita un experto)

Internet dice que .net core se ejecuta dos veces más rápido que mono para tareas computacionales intensivas. El inicio está relacionado con io, primero descargando los binarios y dependencias .dll. (Varios archivos) analizándolos en la memoria. Luego, inicia la aplicación cliente blazor wasm encima. La descarga lleva un tiempo (pero se puede almacenar en caché) y el análisis lleva un tiempo. El compilador aot tampoco sabe cuáles son las dependencias de blazor y cuáles son específicas de la aplicación. Será complicado si siempre establece qué dll incluir en aot wasm. Así que un aot completo se ve bien. (¿Pero será más rápido con la implementación de .net core runtime en lugar de mono? No estoy seguro de nuevo sobre este). Tampoco estoy seguro de si el diseño / implementación de la compilación completa de aot wasm se realiza con mono o .net runtime. Tampoco estoy seguro del progreso.

@ danroth27 ¿Hay algún progreso?

¿Estará disponible en .NET 5?
Sería bueno tener un pre-lanzamiento para verificar esta funcionalidad también;)

@redradist AOT no estará en .NET 5. Están optimizando blazor wasm. Pero por lo que he leído, están haciendo montaje y recorte de campo. y optimizaciones de tiempo de ejecución. Espero que puedan obtener el inicio <1 cuando se almacenan en caché en teléfonos móviles. danroth27 comentario

@hoksource

@redradist AOT no estará en .NET 5. Están optimizando blazor wasm. Pero por lo que he leído, están haciendo montaje y recorte de campo. y optimizaciones de tiempo de ejecución. Espero que puedan obtener el inicio <1 cuando se almacenan en caché en teléfonos móviles. danroth27 comentario

Es triste :(

Tengo una pregunta. Con Blazor AOT estás trabajando en:

1. compilar C # directamente en el formato de código de bytes de WebAssembly
2. o está trabajando en la transformación de IL compilado en .NET DLL en formato de código de bytes de WebAssembly

El enfoque 2) preservaría todas las herramientas .NET (incluida la nuestra) que se basan en IL estándar y metadatos compilados y también en PDB para funcionar. También 2) tendría la ventaja adicional de tener System DLL también compilado a WebAssembly, tal vez con código no se ejecuta en tiempo de ejecución podado (ver el Mono.Linker proyecto @JbEvain).
Gracias

Por cierto, hay muchos recursos sobre Blazor, pero no encontré el que tenía la granularidad adecuada para educarme sobre Blazor Internals, así que lo escribí.

2 no 1

Además, espero que el proceso de AoT genere mapas de origen apropiados (desde wasm hasta C #) para facilitar la depuración.

Espero ver este soporte en el primer trimestre de 2021 para las versiones preliminares de .Net 6. Esto es fundamental para admitir repositorios como SkiaSharp que se ejecutan de forma nativa en el navegador web.

Gracias por contactarnos.
Estamos moviendo este problema al hito Next sprint planning para una evaluación / consideración futura. Evaluaremos la solicitud cuando estemos planificando el trabajo para el próximo hito. Para obtener más información sobre qué esperar a continuación y cómo se manejará este problema, puede leer más sobre nuestro proceso de clasificación aquí .