Open performanceautofiler[bot] opened 2 years ago
This might be result of API additions in https://github.com/dotnet/runtime/pull/76803. @stephentoub @lewing, do we care about that, ie. should we check if we can improve the size after trimming?
This might be result of API additions in https://github.com/dotnet/runtime/pull/76803.
Presumably we can diff a trimmed set of binaries before/after and see where the size difference is coming from?
cc: @eerhardt
@DrewScoggins @LoopedBard3 - it would be great if there were links added to these size regression issues to download the "before" and "after" apps, so they could be manually diffed.
Looking at the chart https://aka.ms/dotnetperfstatus for the SOD - Minimum Blazor Template - Publish - AOT
for .NET 8, you can narrow the commit range down even further to https://github.com/dotnet/runtime/compare/2666e6c...46021ada, which includes https://github.com/dotnet/runtime/pull/76803. Its the bump on Oct 26 for the 2 selected points below:
However, you can also see 2 even worse regressions have occurred since then. The last one looks to be a major mistake where the app size doubled.
Did anyone follow-up on the doubling regression there?
I asked @SamMonoRT about the Blazor WASM size regressions in .NET 8. He said it was on his and @lewing's radar.
@stephentoub - the size regression causing double (or more) app size was due a reporting issue (https://github.com/dotnet/performance/issues/2749) That was fixed and newer graphs don't show that. However there are other smaller regressions in last couple weeks I'm investigating.
Ok, thanks.
Run Information
Regressions in SOD - Minimum Blazor Template - Publish - AOT
Test Report
Repro
Related Issues
Regressions
Improvements