Blazor AOT .Net6 Preview 7 - Still downloading Dlls

[srpeirce]

Describe the bug

I raised this issue previously, but I cannot find anywhere where it is being tracked to see status (apologies if I'm just missing it - happy to be linked to another ticket).

#33730

There are still a large amount of dlls being downloaded with AOT. Perhaps it is my misunderstanding of how it works but I do not expect the dlls, just a larger .wasm file?

Larger wasm file than before AOT:

But still a large number of dlls:

To Reproduce

Install workload: dotnet workload install wasm-tools

Project with RunAOTCompilation set to true.

<PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>
    <BlazorEnableTimeZoneSupport>false</BlazorEnableTimeZoneSupport>
    <BlazorWebAssemblyPreserveCollationData>false</BlazorWebAssemblyPreserveCollationData>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)'!='DEBUG'">
    <!-- Bug in .Net 6 Preview 7 - this should not be non-debug only. https://github.com/dotnet/runtime/issues/55750 -->
    <InvariantGlobalization>true</InvariantGlobalization>

    <RunAOTCompilation>true</RunAOTCompilation>
  </PropertyGroup>

Publish application.

Further technical details

.NET SDK (reflecting any global.json):
 Version:   6.0.100-preview.7.21379.14
 Commit:    22d70b47bc

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19043
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.100-preview.7.21379.14\

Host (useful for support):
  Version: 6.0.0-preview.7.21377.19
  Commit:  91ba01788d

[srpeirce]

CC @javiercn @pranavkm

[pranavkm]

@radical is AOT expected to remove / trim out managed binaries?

[danroth27]

The DLLs are still expected. Even with AOT compilation, there are scenarios where we need to fall back to using the interpreter with the .NET binaries. This increases the download size, but provides a more compatible .NET experience.

[srpeirce]

Thanks for the clarification.

As a follow-up, I was expecting/hoping to see an initial speed boost on application start given the AOT performance compared to interpreted - I haven't done any formal metrics but I don't see any real difference (I have some stopwatches that output some numbers as a crude measure).

Is this to be expected? I had speculated that it might be related to the dlls still being downloaded and used?

[danroth27]

@srpeirce AOT doesn't improve the load time of the app. It actually makes load time worse because it makes the app size larger. What AOT improves is the runtime performance of the app. Blazor WebAssembly in earlier releases uses a .NET IL interpreter implemented in WebAssembly for its runtime. While this interpreter is adequate for many scenarios, it isn't great for CPU intensive tasks. .NET on desktop and server uses JIT compilation to speed things up, but WebAssembly doesn't support JIT scenarios. AOT gives you the performance benefits of JIT compilation by compiling directly to WebAssembly up front. The app size increases because the representation of the high level .NET IL instructions in WebAssembly requires more WebAssembly instructions. So using AOT trades off load time performance for better runtime performance.

[mikes-gh]

@danroth27 What exactly is the dotnet runtime doing after it has been loaded by the browser? The dotnet assets seem loaded quite quickly then a pause of 1.5 secs on a fast machine before the page starts to load the additional assets it needs.

[srpeirce]

Thanks @danroth27 for the detailed explanation, I appreciate your time 👍.

I'll have another play with AOT and decide if the tradeoffs are worth it for us.

Have a great weekend! 🎉

[srpeirce]

Re-opened as I didn't spot @mikes-gh question for @danroth27. Apologies!

[Andrzej-W]

The DLLs are still expected. Even with AOT compilation, there are scenarios where we need to fall back to using the interpreter with the .NET binaries. This increases the download size, but provides a more compatible .NET experience.

@danroth27 DLLs are blocked by firewalls (#31048). Is there any hope that we will be able to create WASM only Blazor application? I prefer to have a little less compatible .NET experience than useless application which cannot be downloaded by some potential users. What are those scenarios where you need to fall back to .NET interpreter?

[mikes-gh]

Re-opened as I didn't spot @mikes-gh question for @danroth27. Apologies!

Thanks - The reason I asked is because I am trying to optimise the startup time of our WASM app. We managed to go from 24MB to 12MB initial payload just by moving to net6 which I presume is down to trimming but the load time wasn't much different. Is there anything else I can look to optimise the wasm app startup time? Maybe this is off topic so apologies if that is the case.

[SteveSandersonMS]

Moving to discussions. @danroth27 let us know if you need any info in this discussion.

[charlesroddie]

The DLLs are still expected. Even with AOT compilation, there are scenarios where we need to fall back to using the interpreter with the .NET binaries. This increases the download size, but provides a more compatible .NET experience.

@danroth27 That's not AOT. Calling this AOT will make it harder to discuss AOT compilation support. There is an AOT issue (#5466) which is marked as completed, but if this means that IL is still being deployed to machines and interpreted then we will need another tracking issue for AOT support.

A linked AOT issue Developers can AOT compile .NET apps into WebAssembly format says that it is full AOT that has been implemented, but what you are saying suggests that it is "mixed mode AOT" which has been implemented.

Is full AOT possible for developers to use or not?

[ivan-prodanov]

@charlesroddie It's not really mixed mode. I haven't tried latest .NET 6 yet, but in the alpha versions 9 months ago the AOT stripped off dlls of their method implementations and left only metadata (class names, method names) I guess probably to be forward compatible with reflection.

[srpeirce]

I don't think they are stripped dlls, they are same download size as interpreted.

[legistek]

The DLLs are still expected. Even with AOT compilation, there are scenarios where we need to fall back to using the interpreter with the .NET binaries.

Dan are there scenarios besides reflection?
And does this mean the WHOLE binary is included or just a pared down version with the metadata? I was almost certain I read that it was the latter.

[Andrzej-W]

I have made a simple test in VS 2022 Preview 3.1 and .NET 6 Preview 7. Default Blazor Wasm ASP.NET Core Hosted project (interpreted) after publication downloads 31 DLLs (total uncompressed size about 2MB) and dotnet.wasm file (also ~2MB uncompressed). With AOT enabled I have exactly the same DLL's but dotnet.wasm is much larger (~13MB uncompressed) and I think it now contains all the code compiled to WASM and the .NET interpreter.

I hope it will possible to remove all DLLs in the future and at the same time remove .NET interpreter. Instead of 32 files (total size ~4MB) we will have one wasm file which will be a little bit smaller (about ~11 MB uncompressed, ~3.5 MB compressed).

Why do we need DLLs and .NET interpreter? I think they are needed for JSON serialization/deserialization. They use reflection and dynamic code generation - both are impossible in WASM. If this is the only reason then maybe we can remove the interpreter and DLLs:
https://devblogs.microsoft.com/dotnet/try-the-new-system-text-json-source-generator/

Of course for those who need reflection there should be an option to include interpreter.

[legistek]

The interpreter shouldn't actually be needed just for reflection. Reflection basically just needs a database keyed with type names and member names. That could be done with an SQLite database or even JavaScript code generators. It shouldn't need the IL bytecode.

If there is something else going on in "AOT" besides reflection that does actually use the bytecode then this is a very significant compromise. I hope @danroth27 or others can provide some clarity. Thanks!

[jeromelaban]

Current builds of .NET 6 AOT are forced into mixed (AOT+Interpreter) mode because of some restrictions (dotnet/runtime#56309) and even if FullAOT (no interpreter) was supported (which cannot be because of the lack of exceptions support in the Wasm spec related to the .NET try/catch when/finally blocks), assemblies will still needed for reflection and many other internal runtime aspects.

Assembly stripping (body removal) is only possible when the code has been fully AOTed and at this point, it's not possible, hence why assemblies are still fully downloaded.

[kenchan97]

um......
disappointed to see this.
expecting Blazor can get some frontend market share from JS

[x6060x]

I'm far from an expert on the topic, but as far as I understand there are multiple wasm-related issues:

• Currently there's no wasm native support for try/catch/when/finally preventing Blazor from going full AOT (causing the performance to be non-optimal)
• Because we can't go full-AOT, that means that we can't have full assembly trimming, meaning that the full original dll-s still need to be sent to the client and interpreted when needed.
• Currently there's no wasm support for DOM-manipulation - so in order to manipulate the DOM, JS interop needs to be used for that
• ...more (such as no wasm multi-threading support in all major browsers)

So my "wild" idea / question would be - is it possible / doable a Blazor-to-JS full AOT compiler to be created, which might solve the first 3 points from my list? Blazor-to-JS interpreted doesn't make sense IMO, because it will be basically do the same thing as what wasm is doing, but with lower speed. If we have full AOT we're going to basically write C# and execure JS after compilation. I tried searching about this idea, but couldn't find anything. Any opinions?

[andriysavin]

@x6060x you're forgetting about CLR which is compiled to wasm and is run almost as native code. .NET code can't just switch from CLR to JS runtime environment.

[r-laf]

It seems wasm exception support is a work-in-progress https://www.chromestatus.com/feature/4756734233018368.

[Stamo-Gochev]

It seems wasm exception support is a work-in-progress https://www.chromestatus.com/feature/4756734233018368.

The V8 blog states WebAssembly Exception Handling is shipped as part of version 9.5 from 21 September 2021, so browsers might get this sooner than expected.

[sorainnosia]

It seems wasm exception support is a work-in-progress https://www.chromestatus.com/feature/4756734233018368.

The V8 blog states WebAssembly Exception Handling is shipped as part of version 9.5 from 21 September 2021, so browsers might get this sooner than expected.

since it is supported now, it is still possible for .NET 6 to include full wasm AOT feature?
if not we will have to wait for .NET 7 which needs a year

[jeromelaban]

Implementing WebAssembly exceptions support in the runtime and AOT compiler is a very large change, touching many areas, and requiring an emscripten update; I would not think it could be done for the next two weeks… 😊

Also, the exceptions spec does not include filtering (catch/with blocks), so there are still going to be interpreter based execution for some BCL portions.

Also, Safari also now has WebAssembly exceptions support implemented: https://webkit.org/blog/12033/release-notes-for-safari-technology-preview-134/

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!

[charlesroddie]

This is the main issue tracking AOT support in Blazor so should be reopened.