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)