Follow up on status of mono-wasm

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

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

.NET 300 ms
WASM: 13155 ms

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.

@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.

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.

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?

@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.

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

dotnet/corert#4659 (comment)

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.

@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.

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?

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

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.

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.

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.

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.

look ressources

A few things:

1. A typical application is downloaded once and run multiple times. Typical non-C# and even non-WASM web sites are much heavier on first visit.
2. The network traffic for the first load is already half the size of the raw modules due to transport compression. Additional improvements in transport compression over what you see here are possible.
3. As should be evident from the fact that AOT did not ship in .NET 5, this is not an optimized set of AOT binaries nor is it a final version of our AOT. In the lead-up to .NET 5 we shaved a massive amount off the size of the interpreter and globalization libraries, you can expect for the same to apply here.
4. A portion of the download time here is due to the number of requests (over 240) and not the file size. Reducing the number of requests will improve the download time (as will the use of HTTP2, if it's not currently in use). This is a well-understood web optimization that is currently not applied in most cases.

It is completely reasonable to have concerns about file size, but it is not especially meaningful to try and draw conclusions about early proof-of-concept builds like this, just like how benchmarking a Debug build of an application is not a meaningful way to measure the performance of Release builds. Once official preview builds are available, we will be extremely grateful to have your feedback and participation in the development process for our AOT implementation.

Most apps I've written are for inner use by company workers, they would benefit from performance more than from initial loading time, even full 200mb JIT runtime load is tolerable. Performance would allow to not write native apps, having one much cheaper and more DRY code base, without inconsistencies and with fast feature release speed. Also UX would improve - share link, open link, wait for load(once, without cache reset, if not needed)

That's why what really bothers me - can AOT performance potentially be as fast as JIT? Practice shows that Java AOT compilers are several times slower than JIT. It worries me, hence I created this issue dotnet/runtime#45471

@ivanivanyuk1993

That's why what really bothers me - can AOT performance potentially be as fast as JIT? Practice shows that Java AOT compilers are several times slower than JIT. It worries me, hence I created this issue dotnet/runtime#45471

What do you benchmark? method ran 1_000_000 times to warmup JIT?, that's cheating and nobody load his web page 1_000_000 times in order to warmup the app

@RUSshy
JS uses JIT, does it need to run 1_000_000 times?

@kg

That's fair but, but i'm still worried

@ivanivanyuk1993

JS uses JIT, does it need to run 1_000_000 times?

even 1_000_000 times, javascript remains slow, if nobody had to recompile code they load from their browser, we'd fix global warming

Benchmark code ran 1 time only, and you'll see how all the managed languages are ridiculed compared to native compiled languages, that's a real world scenario, not a "benchmark scenario"

@RUSshy
JavaScript is the fastest dynamically typed language

I didn't have a case when web app needs to run only once

Nobody paid me or developers I know for fixing global warming

"mono dotnet AOT" is larger
other languages doesn't have this problem

of course they do, write a simple program in c or c++, compile and assemble it and compare the size of the binary with the size of your source code. It will be magnitudes bigger, as expected

@TomBruyneel It happens only due to include pre-processor directive ... Real code from main.cpp takes small size

As the one who made the call on releasing this sample, I can tell you that we haven't spent any time optimizing.

It was a mere attempt at validating that we could make the toolchain work, open the discussion on a "real life" example and have something concrete to point at to identify and raise issues that might still be present in tooling and runtime.

THe dotnet/runtime/WebAssembly team has been beyond fantastic at looking into the issues we've been raising, fixing them in record time and sharing insights.

This is why we're doing this. Not even core to Uno per se but provides a platform to identify issues and collaborate..

We're confident AOT (Profile Guided and/or FUll) can be a more than valid approach to our customers, that is developing Web Apps, not Web Sites, consumed often, where relying on caching makes sense.

The demo done by the Uno team is great and it's nice to see someone actually working on AOT in Blazor. Kudos.

But... It's a far cry from even beginning to see how a real life Blazor app will perform with AOT. Microsoft team, can you give us even a guess as to when we will first see a genuine realistic Blazor app built with AOT?

Hey @jeromelaban with static linking and P/Invoke can you think of any reason COM interop wouldn't be a possible way for C# interpreted WASM modules to consume C++ AOT compiled WASM modules?

Then you could do something almost like UWP where the C# UI objects are really just masks for high performing C++ code.

The demo done by the Uno team is great and it's nice to see someone actually working on AOT in Blazor. Kudos.

But... It's a far cry from even beginning to see how a real life Blazor app will perform with AOT. Microsoft team, can you give us even a guess as to when we will first see a genuine realistic Blazor app built with AOT?

@danroth27 has previously mentioned we should starting seeing Alpha drops of AOT support in the first half of 2021 sometime, as part of a .Net 6 pre-release.

I upgraded my Statistics Simulations in Blazor WASM to .NET 6 Preview 1 and it is roughly ~22-32% faster compared to .NET 5.x RTM. That is a nice measurable difference for just Preview 1 across a variety of device compute (from the interpreter improvements not AoT).

Performance chart below...

@bartczernicki Thanks for sharing!

For anyone who's wondering, Preview 1 does not contain the AOT feature. The speedup observed here is purely due to performance improvements made to the interpreter.

@bartczernicki Thanks for sharing!

For anyone who's wondering, Preview 1 does not contain the AOT feature. The speedup observed here is purely due to performance improvements made to the interpreter.

Well that's darn impressive improvements made in the interpreter. With AOT we're approaching desktop performance baselines. Very excellent!

Difference seems big because it was ultra slow before, so let's not pretend it is fast now.. interpreted is not what people need

Difference seems big because it was ultra slow before, so let's not pretend it is fast now.. interpreted is not what people need

No I agree. But I'm assuming it will not be feasible to AOT entire large applications to WASM as the download size will increase potentially past reasonable download sizes. For apps that are hybrid interpreted/WASM, I'll take any performance improvement.

That is darn impressive!

Of course what would be more impressive is some benchmarks from AOT so we can have an idea what to expect. ;)

Difference seems big because it was ultra slow before, so let's not pretend it is fast now.. interpreted is not what people need

No I agree. But I'm assuming it will not be feasible to AOT entire large applications to WASM as the download size will increase potentially past reasonable download sizes. For apps that are hybrid interpreted/WASM, I'll take any performance improvement.

You say that but I think it depends on the application. If we're talking a website (ecommerce / blog) then yeah, its unreasonable to expect the user to download large binaries. However, if we're talking desktop apps in the browser, i.e video editors, etc, then I don't think large download size is a major concern. Unity WebPlayer had several games that downloaded GB's of data and people still used it.

Plus people can always publish two versions, one interpreted "lite" version and one compiled "full" version and let the user decide what's best for them. (or maybe a "half lite" version with AoT and interpretation combined)