Blazor WebAssembly AOT compilation

[danroth27]

Compile everything to WebAssembly

This work is going to be handled in phases. We're starting from:

• Start experimenting with draft AoT support in runtime #29630

Related .NET 6 users stories:

• Developers can AOT compile .NET apps into WebAssembly format runtime#44316

[danroth27]

Follow up on status of mono-wasm

[danieldegtyarev]

Do you know an issue where we can track progress on this?

[danieldegtyarev]

Current interpreter mode is very slow.
https://dotnetfiddle.net/JUpsRT

.NET 300 ms
WASM: 13155 ms

[danroth27]

Yup, we think this more a result of nothing being optimized yet than an indication that we should move to AoT at this point, but we'll know more as the IL interpreter and AoT support matures.

[stefan-schweiger]

@danroth27 From what I can tell the performance difference between the Mono IL interpreter and the current mono.wasm version is about 5-10x. Overall mono.wasm is about 50-80x and the IL interpreter about 10x slower than a native .NET Core console application.

So the interpreter is currently still not very fast overall and WebAssembly adds even more overhead on top of that.

I would assume that AOT probably still has better chances of speeding things up, but you are right that it's most likely too soon to rule out the interpreter, as most web applications don't even have such high performance demands and will most likely be fine with an interpreted version.

[csnewman]

AOT being more efficient doesn't only matter to intensive applications. It also matters for mobile and other low end platforms, especially when you consider battery usage.

[TheFanatr]

Is there currently any feasible way to enable AoT compilation for Blazor projects? I keep reading blog posts that claim Blazor already has an AoT mode; if this is true, could someone please point to an article explaining how to enable it?

[stefan-schweiger]

@TheFanatr the AOT compilation is dependent on mono supporting this feature. As far as I can tell the last update on the topic was from @migueldeicaza in the Blazor Gitter.

Miguel de Icaza (2018-06-08 19:01):
We are working on it. What happened is this:
The interpreter is using “emscripten” that has a fairly complete libc that we can rely on. And our AOT engine was built on pure LLVM, which requires from us to write the full libc. The latter is the ideal place, because we get native linkers and immedite llvm support and so on. But woudl send us down the path of having to write that libc.
So for the short term, we are moving to emscripten the AOT compiler, make sure that we keep the compatibility. The downside though is that the emscripten tooling is older, so many of the better pieces like the LLVM linker are not available. So we are working through those things.
Basically, we had something done, but we had to start from scratch to work with what we have without forving us to write and emulate everything on our own. We could have attempted to blend those two, but that is also a major effort. So we think we can do emscripten for now via some artful hacks here and there.

So in short, they are working on it, but there isn't a good option to do this with the current public builds.

[stavroskasidis]

Some pretty great progress has just been reported in CoreRT !!

dotnet/corert#4659 (comment)

[plasticalligator]

anyone have an idea on what's blocking this? i might be willing to put in a few trillion manhours to see AOT happen sooner than later now that clientside blazor has been committed to by the powers that be at Microsoft. AOT is going to be really important if we want to develop ( excellent ) PWAs with Blazor.

[danroth27]

@honkmother AoT is being worked on by the mono.wasm folks in the https://github.com/mono/mono repo. I'm sure they would be thrilled to have your help! This issue tracks consuming their work once it is ready.

[plasticalligator]

I think I have a somewhat related question but it isn't well thought out and badly worded- I've been experimenting with ILRepack and Blazor, and managed to package most of the dlls together into a single monolithic blob. Do you guys intend to at any point package the common libraries together as a single dll?

[danroth27]

@honkmother We don't currently have any concrete plans to do so, but we'd be interested to hear the results of your experimentation.

[plasticalligator]

I was able to merge most of them together by just using ILRepack on the /dist/bin/ output, and including System.Core.dll. Startup times were improved after combining most of the libraries, but it introduced a lot of head-scratching bugs that I have no idea how to solve; and of course you're losing out on the ability to rely on caching for updated pieces of code without having to download the entire blob again.

[legistek]

So have there been any developments on this or at least an ETA? Server-side is working quite well but client-side WASM performance through the interpreter is still unacceptable as soon as the DOM gets reasonably complex.

[plasticalligator]

I don't think so, the AOT on the mono repo still seems to be a WIP; I heard we'll have it by Q1 of 2020 but I don't know if that's for certain; which is sad because I have a very nice PWA set up with client-side but it has some performance issues that AOT would probably alleviate without needing dirty hacks.

In the meantime are some things you can do to alleviate the pain there, namely using virtual DOM and/or using RenderTreeBuilder directly so that you're not rendering everything at once and have some control over what's going on.

[legistek]

Well, I was also wondering if anything has changed in light of the announcement a few months ago about .NET 5. Interesting quote there:

The Blazor project is already using the Mono AOT. It will be one of the first projects to transition to .NET 5. We are using it as one of the scenarios to prove out this plan.

Do they know something we don't?

In the meantime are some things you can do to alleviate the pain there, namely using virtual DOM and/or using RenderTreeBuilder directly so that you're not rendering everything at once and have some control over what's going on.

Indeed. I am making an MVVM framework from scratch inspired by WPF and one of the first things I do is override ShouldRender to turn off Blazor's automatic render triggers and instead rely on property changes to tell components when to re-render. In fact one HUUUUGGGE performance improvement comes by updating styles through JS interop, rather than StateHasChanged, whenever possible.

Nonetheless, I'm having issues when large DOMs need to be generated up front - for example, a complex list or data grid. Server side is fine, but client side takes 5-10 seconds sometimes just to initially render.

What we really need is a VirtualizingPanel like in WPF. I have been thinking extensively about how this could be implemented in Blazor and JS interop, but a complete solution still eludes me. In WPF it works because the framework is responsible for measuring every visual element and reporting its size. Even with JS interop I'm not sure the same thing is possible, and I've yet to see a good generalized solution for this in any web framework.

[Xyncgas]

I was talking about using blink's rendering perhaps, without v8.

[Xyncgas]

by the way I don't know why people lost confident in silver light, it seems like a good idea now to have a plug-in that runs seperately, which means it doesn't have to sit inside browsers too, imagine, if we didn't abandon it we can have entire website/app built using silverlight and run on many platform and either natively or in browser ahead of the industry.

[Xyncgas]

Security might've been a problem for adobe flash, I mean microsoft has been managing .net runtime just fine

[juepiezhongren]

wasm is also executed by v8

[acaly]

In fact, it sounds like wasm is closer to “normal”/“real” machine instructions than Java bytecode or .net IL is. And it does this precisely to support getting performance similar to traditional compiled C code and to be able to be a target for such languages. ... because wasm is too low-level to be directly targeted by .net

That's an impression many might have, but actually, how the bytecode is designed does not itself determine how fast the code executes. And the difficulty for targeting wasm is also not only because it's low level. Obviously the team have targeted many assembly languages, which are definitely much lower than wasm. In some cases, like the GC, it's instead because it does not expose some low-level functionality. The design of wasm still has concerns of safety, as long as it needs to run in browsers.

[Trolldemorted]

Yes, download size is with Webassembly not so much the issue but the startup size.

How big are your wasm binaries? My binaries are >8 MB which has a serious impact on the download speed on mobile and old devices

[IIARROWS]

by the way I don't know why people lost confident in silver light, it seems like a good idea now to have a plug-in that runs seperately, which means it doesn't have to sit inside browsers too, imagine, if we didn't abandon it we can have entire website/app built using silverlight and run on many platform and either natively or in browser ahead of the industry.

People didn't lost confidence in Silverlight, it required a plugin that was available only on Windows and on Internet Explorer. In a period mobile phones were on the rise for application use and web browsing. It didn't met the accessibility and availability criteria of the time and for the future.

[Pinox]

@ivanivanyuk1993 running your link on edge I get 71ms for c# and 258ms for js.

if i run the js first on the page in chrome i get around 74ms , then after I run c# then the js falls back to 258ms , same for Edge. If you run js first after initial load then it's fast at around 75ms , if not then the js version gets 258ms. Vey weird results for js within blazor. ( 75ms after initial load , 258ms thereafter )

[Xyncgas]

Yes, download size is with Webassembly not so much the issue but the startup size.

How big are your wasm binaries? My binaries are >8 MB which has a serious impact on the download speed on mobile and old devices

If that's a problem your app can do something or at least standing there looking pretty until it's ready

[Xyncgas]

by the way I don't know why people lost confident in silver light, it seems like a good idea now to have a plug-in that runs seperately, which means it doesn't have to sit inside browsers too, imagine, if we didn't abandon it we can have entire website/app built using silverlight and run on many platform and either natively or in browser ahead of the industry.

People didn't lost confidence in Silverlight, it required a plugin that was available only on Windows and on Internet Explorer. In a period mobile phones were on the rise for application use and web browsing. It didn't met the accessibility and availability criteria of the time and for the future.

so microsoft lagged behind? you are saying they could've idk make silver light into something that runs in the mobil and in other operating system too?

[KieranDevvs]

Yes, download size is with Webassembly not so much the issue but the startup size.

How big are your wasm binaries? My binaries are >8 MB which has a serious impact on the download speed on mobile and old devices

You consider 8MB big with the majority of the planet using 3G 4G or 5G? I have seen websites have images bigger than 8MB. YouTube videos are several hundred / thousand. Even if your argument was older devices, like... How old are we talking for an 8MB download to be an issue?

Also you're viewing WASM as a concept for traditional websites... That's not how you should be thinking about this, WASM is intended for web applications, not static website content. If your load times aren't instant because you have to spend 4 seconds download some resources for a web application that will let you edit videos, is that really an issue?

Here's Doom 3 running on WASM, the initial resource download is about 150MB and the total shareware assets are about a gigabyte collectively. I don't know about you but this runs fine for me.
https://wasm.continuation-labs.com/d3demo/

GMail alone loads just under 7MB over the wire and a total of 20MB+, I've never had an issue loading GMail on any device at any time period.

[Oblomoff]

@KieranDevvs

You consider 8MB big with the majority of the planet using 3G 4G or 5G?

Yes. Please note that modern websites can be responsive in as little as 3-5 seconds. And half of the users will close the page if it takes more than 14 seconds to load with only a white screen. But it is not important. The important thing is that most developers will refuse to use such a huge framework.

[Trolldemorted]

You consider 8MB big with the majority of the planet using 3G 4G or 5G?

Yep, even wired internet connections in my country are often just 16 mbits, and the page load impact of an 8mb download upfront is significant there.

YouTube videos are several hundred / thousand

Completely irrelevant, they are not affecting the page load and are consumed over time.

Also you're viewing WASM as a concept for traditional websites... That's not how you should be thinking about this, WASM is intended for web applications, not static website content. If your load times aren't instant because you have to spend 4 seconds download some resources for a web application that will let you edit videos, is that really an issue?

For doom or whatever niche stuff the 4s page load does not hurt, but blazor is a web framework, not a game engine. If you are selling a web framework, expect lots of users to build simple CRUD webapps with it.

Please note that modern websites can be responsive in as little as 3-5 seconds. And half of the users will close the page if it takes more than 14 seconds to load with only a white screen. But it is not important. The important thing is that most developers will refuse to use such a huge framework.

One might even say modern websites can be responsive in 1-3 seconds, and what users do is very important - I have had complaints from users because the initial page load is too high, and they assumed the site was broken, which I can totally understand. It takes way more than 5s to open my simple CRUD app in a new firefox private tab on my smartphone, even when it is connected to 250mbit wifi.

No serious business will choose blazor wasm if the startup times without hot caches do not improve. The longer your website loads, the more users you will annoy, and the fewer customers you are gonna have.

[Xyncgas]

If you so worried about responsive just put everything on static html that people are loading before your blazor is running

[Xyncgas]

blazor isn't that different on the surface to other frameworks like react, look at https://twitch.tv :it's big, it loads a bunch of stuffs, and it's responsive under 1 sec

[Trolldemorted]

If you so worried about responsive just put everything on static html that people are loading before your blazor is running

It would still be unresponsive for several seconds though

blazor isn't that different on the surface to other frameworks like react, look at https://twitch.tv :it's big, it loads a bunch of stuffs, and it's responsive under 1 sec

It loads significantly less stuff before it is responsive, which naturally allows it to become responsive faster. Same with gmail, they ship an entire mail app in 640kb, whereas a simple hello world in blazor is literally more than 10 times that size,

[SteveSandersonMS]

gmail, they ship an entire mail app in 640kb, whereas a simple hello world in blazor is literally more than 10 times that size,

Just FYI, a minimal Blazor WebAssembly "hello world" isn't 6MB. This one is ~ 1.1MB. I know that's still huge for "hello world" but of course most applications aren't "hello world", and the size will grow sublinearly with the amount of added functionality.

I agree with your other points. Only posting this in case anybody else gets an incorrect idea. Hope that's OK! :)

[MichaelPeter]

Hello @SteveSandersonMS,

just something curious I just noticed with your sample.

If I load your link in Edge or Chrome it is indeed 1.1 Megabyte. But if I load it in Firefox incognito Mode it is 2,72 Megabyte. I use incognito mode since with .NET 6, Blazor does still caches it's files with Control+F5

First I thought this is Firefox Display error, but for some reason with chrome, dotnet.wasm is 394 kbit and with firefox about 1 Megabyte:

Left Edge, Right Firefox

Does this firefox version not yet support ceartain webassembly features?

Firefox Version 89.0.1

[MarkusRodler]

@MichaelPeter It's only an other style of displaying information. Chromium tells you the actual number of downloaded bytes (this is heavily compressed with brotli) and Firefox tells you what the umcompressed size is on disk

[Andrzej-W]

@MichaelPeter , @MarkusRodler unfortunately it is sometimes a little more complex than that. I have checked the app from @SteveSandersonMS post (https://minblazor.anthonychu.com/) and here is what I see in current version of Edge (and any other browser):

Transferred size is big. Why? Because I have good antivirus program 😄 It monitors my HTTPS traffic and each time there is gzip, brotli, or any other compressed payload it is decompressed and scanned. Then content-encoding: br HTTP header is removed and uncompressed data stream is passed to web browser.

I have disabled my antivirus program and here is what I see now:

Hopefully it is useful information for you and others. For those interested I have ESET Internet Security but I believe this is common feature in other antivirus programs also.

[acaly]

It monitors my HTTPS traffic and each time there is gzip, brotli, or any other compressed payload it is decompressed and scanned.

Wait, what? I didn't know antivirus program is able to decrypt https payloads. Those should only be accessible by my own application, right? Or is the browser itself has a special API to communicate with antivirus?

[IIARROWS]

Or it acts as a proxy (aka man in the middle attack)

[daniel-p-tech]

Just FYI, a minimal Blazor WebAssembly "hello world" isn't 6MB. This one is ~ 1.1MB. I know that's still huge for "hello world" but of course most applications aren't "hello world", and the size will grow sublinearly with the amount of added functionality.

@SteveSandersonMS can we expect the size to go down even further? What is the ultimate goal? What is the size of AOT'd "hello world" app?

Based on various comments on this topic that I've run across, it seems that one of the major contributors to large app size is GC which will be eventually handled by WASM. Honestly, I'm a bit disappointed with rather slow WASM progress - it has been I believe 4 years since MVP and threads/GC are still not available. Now that Microsoft is dedicating substantial resources into developing/promoting Blazor, is the company going to drive (or at least encourage) some of the most critical WASM improvements?

Thanks.

[KieranDevvs]

If you so worried about responsive just put everything on static html that people are loading before your blazor is running

It would still be unresponsive for several seconds though

blazor isn't that different on the surface to other frameworks like react, look at https://twitch.tv :it's big, it loads a bunch of stuffs, and it's responsive under 1 sec

It loads significantly less stuff before it is responsive, which naturally allows it to become responsive faster. Same with gmail, they ship an entire mail app in 640kb, whereas a simple hello world in blazor is literally more than 10 times that size,

These comments are really bizzare. You realise Blazor / WASM isn't the first technology to try this? Do you remember the web in the early 2000's with Flash, Shockwave, Java applets, Silverlight etc. Java applets and flash noted for being significantly popular with comparable download sizes? They didn't fail because of their "lack of response" or their "huge download times", they failed because of the inability to fortify the sandbox.

I built several Java applets that were 5MB+ in size and users had no issues even without caching.

Id also encourage people to look at average global internet speeds for both mobile and fixed connections:
https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds

With Blazor, you're not just getting a C# interface to the DOM (not in the API sense), you're getting a whole .NET runtime. If you're planning on using Blazor to host a few images and a bit of text and you're concerned with download sizes, you have to ask yourself.... Why?

Do you really need native speeds and a whole new runtime and application download for your "simple crud" application?

Anyway, this is a pointless debate because its so subjective, I cant objectively say your opinion is wrong. If you don't like the technology or it doesn't fit your needs, then simply don't use it.

[bachratyg]

I'm not building apps for the average user. I'm building apps for a wide range of users from rural to metropolitan. For one such app - quite more complex than a simple crud - some users need to connect while on the road through the middle of nowhere. That means both network bandwith (small app size) and battery life (no CPU hogging) is important, and until Fiber To The Highway(tm) becomes reality this is not going to change even if the country average is boosted by new gadgets in downtown.

Ideally Blazor should be able to cover a wide range of requirements (not just the average) and meet or preferably surpass current client stacks (e.g. Angular), and I strongly believe it will given time. If not then the need to maintain know-how in multiple stacks pretty much defeats its main purpose.

Just my $.02

[Oblomoff]

Do you remember the web in the early 2000's with Flash, Shockwave, Java applets, Silverlight etc. Java applets and flash noted for being significantly popular with comparable download sizes?

Yes, I do. Nobody used Java applets, much less Silverlight, just a couple of geeks. And Flash size was quite small. Plus, Flash was only used for games and animation. But when Macromedia Flex came out (you know what it is?) nobody used it to build UI. Flex, Java applets, and Silverlight were stillborn technologies.

[KieranDevvs]

I'm not building apps for the average user. I'm building apps for a wide range of users from rural to metropolitan. For one such app - quite more complex than a simple crud - some users need to connect while on the road through the middle of nowhere. That means both network bandwith (small app size) and battery life (no CPU hogging) is important, and until Fiber To The Highway(tm) becomes reality this is not going to change even if the country average is boosted by new gadgets in downtown.

Ideally Blazor should be able to cover a wide range of requirements (not just the average) and meet or preferably surpass current client stacks (e.g. Angular), and I strongly believe it will given time. If not then the need to maintain know-how in multiple stacks pretty much defeats its main purpose.

Just my $.02

While I agree with everything you posted, I think we differ on the technicalities of what constitutes as small bandwidth in respect to modern infrastructure and devices. Don't take my two cents as a reason not to improve upon Blazor. It has a long roadmap ahead of it, I just don't believe its reasonable to think an 5-15MB download, even on rural cellular connections, is absurd, especially when you factor in content caching.

[Xyncgas]

I'm not building apps for the average user. I'm building apps for a wide range of users from rural to metropolitan. For one such app - quite more complex than a simple crud - some users need to connect while on the road through the middle of nowhere. That means both network bandwith (small app size) and battery life (no CPU hogging) is important, and until Fiber To The Highway(tm) becomes reality this is not going to change even if the country average is boosted by new gadgets in downtown.
Ideally Blazor should be able to cover a wide range of requirements (not just the average) and meet or preferably surpass current client stacks (e.g. Angular), and I strongly believe it will given time. If not then the need to maintain know-how in multiple stacks pretty much defeats its main purpose.
Just my $.02

If you are building app for a large audience, and you are not going to make excuses for the lack of your skills and budgets and faiths, because that can be quite disturbing considering yelling at others can't let them solve the problems quicker, you do know that webassembly is fetch and compiled using javascript that's why there is a javascript file attached to your blazor project, well, write your own, give people a static page that's going to work partially, while hot-loading some of the functions (that you compiled as webassembly modules) in the background.