Performance Regression in Blazor WebAssembly with .NET 9

Pvxtotal commented 1 month ago

Is there an existing issue for this?

[x] I have searched the existing issues

Describe the bug

After upgrading to .NET 9 (including RC2), I've encountered significant performance issues in my Blazor Web App (WebAssembly Global). Specifically, the application frequently freezes for seconds before switching to Interactive WebAssembly mode. The overall application performance feels slower compared to .NET 8.

In some cases, the app remains frozen in SSR mode and never enters Interactive Mode. This behavior is consistent across different machines, so I believe it is not hardware-specific.

Reproduction Steps The app is built using the Blazor Web App template, configured for WebAssembly Global. Prerender is turned off. I've tested it across multiple machines with the same results using AMD Ryzen CPU.

The delay before entering Interactive Mode in .NET 9 is noticeably longer than in .NET 8. See the comparison below:

.NET 9 Demo: https://github.com/user-attachments/assets/bb4e30dc-90c6-4a26-9beb-f0b418ba5e9c

.NET 8 Demo: https://github.com/user-attachments/assets/7cc03af3-7219-4ba4-ba96-b73a1fa89c3d

While publishing with wasm-tools slightly improves performance, the delay before entering Interactive Mode is still present.

The issue persists regardless of whether I use Release or Debug modes.

Additional Information Environment: Debugging in Visual Studio 2022 Preview 17.12.0 with .NET 9 Blazor often crashes, leading to a poor debugging experience.

Request It would be helpful to know if others have experienced similar performance regressions or if there are any recommended workarounds or fixes in .NET 9 for this issue.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

9.0.100-rc.2.24474.11

Anything else?

No response

Gabrieldsantos96 commented 1 month ago

Up

javiercn commented 1 month ago

@Pvxtotal thanks for contacting us.

It's not clear to us if you uploaded the same video twice, but we can't appreciate the regression that you are mentioning.

In order for us to get a better understanding of the problem you seem to be facing; can you use the Performance API to get precise numbers on performance?

It's also important to make sure that: 1) You are always testing in release mode. 2) You are running against the published app.

Pvxtotal commented 1 month ago

@Pvxtotal thanks for contacting us.

It's not clear to us if you uploaded the same video twice, but we can't appreciate the regression that you are mentioning.

In order for us to get a better understanding of the problem you seem to be facing; can you use the Performance API to get precise numbers on performance?

It's also important to make sure that:

You are always testing in release mode.

You are running against the published app.

Update:

After running tests using the Performance API in both Release Mode and Debug Mode, it seems the performance regression is only apparent in Debug Mode. Below are the detailed results, including the full JSON objects:

Release Mode Results:

.NET 8:

1st Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 229,
  "duration": 1570.800000000745
}

2nd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 180.39999999850988,
  "duration": 1544
}

3rd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 233,
  "duration": 1554.4000000003725
}

.NET 9:

1st Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 218.7999999988824,
  "duration": 1490
}

2nd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 196.80000000074506,
  "duration": 1520.5999999996275
}

3rd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 231,
  "duration": 1472.5
}

In Release Mode, both .NET 8 and .NET 9 have similar performance, with no significant differences in the time taken to switch from SSR to Interactive Mode.

Debug Mode Results:

.NET 8:

1st Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 147.5,
  "duration": 2763.800000000745
}

2nd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 145.2999999988824,
  "duration": 2825.300000000745
}

3rd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 185.09999999962747,
  "duration": 2750
}

.NET 9:

1st Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 291.7999999988824,
  "duration": 3264.300000000745
}

2nd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 351.19999999925494,
  "duration": 3019.9000000003725
}

3rd Run:

{
  "name": "from_page_load_to_interactive_mode",
  "entryType": "measure",
  "startTime": 184.7000000011176,
  "duration": 3281.5
}

In Debug Mode, the performance in .NET 9 is noticeably slower compared to .NET 8, with durations increasing by around 500 ms in most cases.

Additional Observations:

While analyzing the videos, make sure you notice that the fonts and interactive assets (e.g., the Header component, the search bar) load significantly faster in .NET 8 compared to .NET 9. This is especially apparent in the .NET 8 video, where the fonts (loaded dynamically by a custom logic MainLayout.razor) and the interactive Header are fully loaded and displayed much earlier in the page load compared to .NET 9.

Conclusion:

It appears the performance issue is specific to Debug Mode. In Release Mode, both versions perform similarly, and there’s no major regression. However, Debug Mode in .NET 9 shows a clear degradation in the time it takes to enter Interactive Mode compared to .NET 8.

Please let me know if there are any additional steps you would like me to take to further investigate this issue.

Thank you for the support!

javiercn commented 1 month ago

@Pvxtotal thanks for the additional details.

Are you using MapStaticAssets() in your app?

If so does setting "ReloadStaticAssetsAtRuntime": false in your appsettings.Development.json improve the timings?

If that's so, this is likely caused by the new routerware behavior we use during development. In order to prevent staleness issues with assets getting cached during development, we include a no-cache cache response header on all assets.

The main difference in timing comes from the fact that this new behavior more accurately reflects a cold page visit vs over a warm visit where the assets were already present in the cache.

Pvxtotal commented 1 month ago

@Pvxtotal thanks for the additional details.

Are you using MapStaticAssets() in your app?

If so does setting "ReloadStaticAssetsAtRuntime": false in your appsettings.Development.json improve the timings?

If that's so, this is likely caused by the new routerware behavior we use during development. In order to prevent staleness issues with assets getting cached during development, we include a no-cache cache response header on all assets.

The main difference in timing comes from the fact that this new behavior more accurately reflects a cold page visit vs over a warm visit where the assets were already present in the cache.

I'm not using MapStaticAssets(), but rather app.UseStaticFiles(). However, I did try switching to MapStaticAssets() to see if it would improve performance, but unfortunately, it didn't make any noticeable difference in the load times.

In my case, the delay seems to be coming from the time it takes for Blazor WebAssembly to enter interactive mode, not from static assets. I haven't tried setting "ReloadStaticAssetsAtRuntime": false in appsettings.Development.json, but since the static assets don't seem to be the bottleneck, I'm focusing more on the WebAssembly initialization.

javiercn commented 1 month ago

@Pvxtotal thanks for the additional details.

This is happening within Visual Studio, isn't it? And potentially only happening when you are trying to attach the debugger? (Does it happen if you run without the debugget? (CTRL+F5))

We are asking you these questions to try and narrow down the possible cause of the issue so that we can loop in the right folks.

Pvxtotal commented 1 month ago

@Pvxtotal thanks for the additional details.

This is happening within Visual Studio, isn't it? And potentially only happening when you are trying to attach the debugger? (Does it happen if you run without the debugget? (CTRL+F5))

We are asking you these questions to try and narrow down the possible cause of the issue so that we can loop in the right folks.

Thank you for the follow-up. Yes, the slowness only occurs when I have the debugger attached within Visual Studio (Version 17.12.0 Preview 3.0). When I run the application without the debugger using CTRL+F5, the performance issue does not happen, and everything runs smoothly. This leads me to believe now that the issue might be tied specifically to the debugging process or how the debugger interacts with the application.

I'm really sorry I didn't notice that before.

javiercn commented 1 month ago

@Pvxtotal thanks for the additional details.

Could you follow up the instructions https://learn.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2022 to report the problem through VS?

That will capture additional information from your environment that will help the teams in VS analyze the issue in more depth. Link this issue in the VS bug comments and post the link to the VS issue back here.

Please also make sure that the issue clearly indicates that the debugger is causing the slowdown, but once you post the issue here, I'll ping the relevant folks.

Pvxtotal commented 1 month ago

@Pvxtotal thanks for the additional details.

Could you follow up the instructions https://learn.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2022 to report the problem through VS?

That will capture additional information from your environment that will help the teams in VS analyze the issue in more depth. Link this issue in the VS bug comments and post the link to the VS issue back here.

Please also make sure that the issue clearly indicates that the debugger is causing the slowdown, but once you post the issue here, I'll ping the relevant folks.

I created a ticket: https://developercommunity.visualstudio.com/t/Performance-Regression-debugging-Blazor/10773897

I'll leave this issue open, but feel free to close if it fits. I have hope that this problem will be fixed before .NET 9 GA early November.

@javiercn I'm really thankful for the support so far!

javiercn commented 1 month ago

@Pvxtotal thanks for filing the issue through VS, I've pinged the relevant folks in Visual Studio. As for timelines, since this is a VS related issue, the timelines might be slightly different. Will depend on the results of the analysis and the fix we come up with.

javiercn commented 1 month ago

@Pvxtotal can you try disabling the new mono debugger and see if that improves the situation?

It will also help us if you have a project that can reproduce the issue.

Pvxtotal commented 1 month ago

@javiercn I'm testing it now.

Also, when I tried to debug before disabling the new Mono debugger, Visual Studio froze when I attempted to type into a simple input field. I had to terminate the process via Task Manager. This is happening often.

Pvxtotal commented 1 month ago

@Pvxtotal can you try disabling the new mono debugger and see if that improves the situation?

It will also help us if you have a project that can reproduce the issue.

@javiercn Tested it.

I can confirm that disabling the new .NET 9+ Mono Debugger resolves all issues, including freezing, delays, and more.