Size regression in Blazor WASM apps

[eerhardt]

Looking at https://aka.ms/dotnetperfstatus, there is a 140KB size regression in the default Blazor WASM app size between the following commits:

dotnet/runtime@6b83269...06228c1

SOD - New Blazor Template - Publish

SOD - New Blazor Template - Publish - AOT

We should investigate what change caused this size regression and if there is anything that can be done.

From looking at the charts, some of it comes from System.Private.CoreLib:

Before

After

But the biggest file that added here is System.Linq.Expressions.dll. It isn't in the Before, but in the After it is over 100KB itself:

After

Maybe a new ASP.NET change now brings in Linq.Expressions by default? cc @SteveSandersonMS @captainsafia

cc @lewing @SamMonoRT

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Looking at https://aka.ms/dotnetperfstatus, there is a 140KB size regression in the default Blazor WASM app size between the following commits:

dotnet/runtime@6b83269...06228c1

SOD - New Blazor Template - Publish

SOD - New Blazor Template - Publish - AOT

We should investigate what change caused this size regression and if there is anything that can be done.

From looking at the charts, it mostly comes from System.Private.CoreLib:

Before

After

cc @lewing @SamMonoRT

Author:	eerhardt
Assignees:	-
Labels:	arch-wasm, tenet-performance
Milestone:	-

[pranavkm]

@eerhardt I'm gonna guess it's this change: #18088. We switched Blazor to use ActivatorUtilities.CreateFactory to initialize components which I can see uses System.Linq.Expressions.

[eerhardt]

Moving to aspnetcore, since that is what caused this regression. There isn't anything dotnet/runtime can do here.

[SteveSandersonMS]

It's really great that we're able to detect this kind of thing systematically. Thanks for letting us know, @eerhardt!

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[pranavkm]

@eerhardt do you think there's a way to update ActivatorUtils to ILEmit the way ServiceProvider does for apps targeting .NET Core? That would help in this case, no?

[eerhardt]

do you think there's a way to update ActivatorUtils to ILEmit the way ServiceProvider does for apps targeting .NET Core? That would help in this case, no?

I think that could help here. System.Text.Json is already using Reflection.Emit directly. And the Linq.Expressions code Compiling a Lambda function is already using it as well. So re-writing this code to use Ref.Emit directly would cut Linq.Expressions out of the equation.

[pranavkm]

We could approach it this way - I'll roll back the change citing this regression. We're on strike two because this is also a source-breaking change. I'll file a runtime issue to consider changing ActivatorUtils to use ILEmit (when possible). If that lands in 7.0 and we can verify there isn't a size regression, we'll add the change back in.

@SteveSandersonMS how does that sound?

[eerhardt]

Another thing to consider is dotnet/runtime#38439, and NativeAOT in general. Using Linq.Expressions allows the underlying implementation to be switched out (interpreter vs ILEmit). Where if you jump directly to ILEmit, you would need to do the switching yourself.

So we may need to check RuntimeFeature.IsDynamicCodeSupported here.

[SteveSandersonMS]

[Pranav] how does that sound?

Yep, great - thanks. Rolling this change back does feel right. Maybe activation-by-default could come back in the future if the underlying implementation is updated, but it's not a big loss to tell customers they can do this themselves in user code.

[mkArtakMSFT]

Closing this as we've reverted the change which contributed to this.