Reapplying hot reload deltas on load can cause browser hang

[SteveSandersonMS]

The repro steps here are just "create a Blazor WebAssembly hosted app and make a lot of hot reload polite edits in sequence". In my case I had tailwind.min.css referenced, but I'm not sure that's necessary to produce this effect. Note that I did not have Browserlink enabled (and hence its JS was not loaded):

To get here, I made about 30 HTML-only edits to .razor files in succession, then pressed ctrl+r to reload the page. The browser hung for 10-20 seconds while the app was trying to get started. As you can see from the screenshot, applyHotReload is eating up all the CPU time. I say "10-20 seconds" because it's really about 10 seconds, but if you are recording a performance profile, that makes everything much slower hence 20 seconds in the screenshot.

This is particularly awkward because you can't make the problem go away by reloading the page. In fact, that's what leads to the hang in this case. You can only make the problem go away by restarting the application.

[pranavkm]

@SteveSandersonMS I don't see a browser hang per se with this, although I do see that the time it takes for the UI to update becomes increasingly visible the larger the number of deltas are available. Our current APIs only allow for a single delta to be applied at a time which works well when you only during ordinary development since that's usually the number of deltas produced.

This becomes problematic in the reload case especially if you have about a handful (in my machine ~15 was noticeable) or more deltas to be applied. We treat each apply as a regular hot reload event, and end up discovering and executing metadata handlers. I tried a fix for this which involves receiving a list of deltas which avoids the additional overhead involved with metadata handlers. This helped a bit. A further optimization might be to figure out if we are able to compact these deltas since this still would still run in to some walls if you have large number of changes queued up, but perhaps that could wait until we hear from users.

My plan was to consider a change for 7.0 (related - I want to be able to make JSInterop support non-public APIs for the framework) since this change would involve an API change. If we hear from users about it being untenable for 6.0, we could finagle a way in a 6.0.x release.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 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.