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.