Hot Reload Takes Nearly 45 Seconds to Update

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work]
Please see attached. Hot Reload now works for me, but takes forever to update, nearly 45 seconds to be more precise.

---

Original Comments

Feedback Bot on 11/11/2021, 03:48 PM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

---

Original Solutions

(no solutions)

[mkArtakMSFT]

@pranavkm I know that you've been looking into this already. Is there another issue to dupe this against?

[NTaylorMullen]

More reports:

• https://developercommunity.visualstudio.com/t/VS2022-with-Blazor-Server-project-is-ter/1584485

[Mercurial]

same for me its just not flawless yet... :(

[CommonLoon102]

This is a duplicate of dotnet/aspnetcore#32867.
Workaround can be found here:
https://developercommunity.visualstudio.com/t/Hot-Reload-in-VS-very-slow-but-fast-wit/1563649

[MichelJansson]

I have similar issue, but just a lot worse.

For a slightly complicated page (~450 lines of razor, a few loops etc.) hot-reload from VS2022 takes 2:30 (2 minutes and 30 seconds) of really hammering the CPU to apply changes, and after that the changes still does not get rendered, and I have to restart the app.

Using the suggested workaround using dotnet watch it "only" takes 50-80 seconds. But now it actually also renders the changes.

It's only this extreme for this particular page. For very simple pages it's working OK, and changes are applied within 10 seconds. I've tried to find if it's any particular code on this page that is "bad" by process of elimination, and I can't find any specific error but in-line loops just seems to absolutely kill the performance.

[Mike-E-angelo]

I do apologize for the confusion here. According to this comment, this should have been addressed in preview2? This was my understanding when I posted my last comment, which seems to have contributed to the issue being locked. 😇

But now it appears with subsequent updates that this is slated for .NET7, if I understand correctly. I am totally fine with this as long as it is being communicated correctly so that we're not operating under false impression/understanding. For instance, I wouldn't have posted my last comment on dotnet/aspnetcore#32867 as I was under the impression that a fix had already been checked in as per the previous comment (which I probably misunderstood).

In any case, please know that I for one truly appreciate all the effort being applied there with this task and the project as a whole. You are truly moving mountains over there. 🙏

[CommonLoon102]

Based on this PR, it is being backported to .NET 6.0.3:
dotnet/sdk#23419

It was told that it will come in VS 17.2 (see last comment in the PR linked above). I don't know the ETA for that. Even 17.1 is yet to be released.

[Mike-E-angelo]

Ahhhhh 17.2, not to be confused with 17.1 Preview 2, as I was doing. :) Thank you for the pointer and correction, @CommonLoon102.

[pranavkm]

@Mike-E-angelo 17.2 preview1 would ship the same day 17.1 ships (part way thru February 2022).

[CommonLoon102]

17.2 Preview 1 is out but it is still 40 seconds to do a "hot" reload.

[Mike-E-angelo]

Not really related to this issue other than if I wasn't doing this, then I wouldn't be here in the first place. :) I recently announced my product that is built on your tech and is responsible for finding all these issues. 😁

https://alpha.starbeam.one/about/acknowledgements

I have a shout out to you there @pranavkm. Thank you for all your great work over there. 🙏

[aqim-dev]

Me and my team are working on a big scale project right now and we decided to update to .NET 6.0 and we have the same issue with our windows users. It looks like it works perfectly fine in the M1 Mac version. Also we noticed that some of our code that includes SQL Server works slower, noticeably slower. I, myself, use hot reload very much but i don't mind debugging every time, but it's the same speed so i do not bother.

[Mike-E-angelo]

dotnet/sdk#24538

🤔

[Mike-E-angelo]

No comment given on the reversion, but it appears it was leading to problems such as this one, which I ran into yesterday:
https://developercommunity.visualstudio.com/t/perpetual-15-20-cpu-churn-by-servicehubroslyncodea/1703772

(Reference: #5697 (comment))

[CommonLoon102]

Is there still any hope that the community will get a 3-4 seconds hot-reload time instead of 40-45 seconds? Is this still considered fixable? The issue is there since .NET 6 release and the new previews didn't bring any improvements. I also can't see a fix for this in the .NET 7 roadmap. I'm asking because we need to consider this when we deciding about the technology we want to use in new projects.

[Mike-E-angelo]

Not looking too promising here. Any further update, @pranavkm?

[uecasm]

I do most of my development using dotnet watch -- the hot reload rarely takes more than 5 seconds there. At least when it deigns to use it, anyway; there's a lot of seemingly innocuous changes that it apparently considers to be rude. The VS debugger seems a bit random on whether it will stop on breakpoints or not anyway, so I try to use it only when I can't find out what the app is up to any other way.

[CommonLoon102]

I do most of my development using dotnet watch -- the hot reload rarely takes more than 5 seconds there.

It depends on the file you edit. I have files which reload in a second with dotnet watch, others take more, some can take up to 45 seconds. Although I just change some text in a <span>, it still takes 45 seconds...

[chsienki]

For the VS hot reload performance we have a PR out in the SDK repo, which should improve things. dotnet/sdk#24928

For dotnet watch and even faster VS we have some ideas of how to improve the performance, but don't have any concrete timelines yet.

[Mike-E-angelo]

Thank you for taking the time to update us, and for all your efforts out there @chsienki & team. 🙏

[phil-allen-msft]

@Mike-E-angelo , we've made some pretty significant changes to help address this in the past year and are continuing to make investments in this area. That said, what is your current experience with Hot Reload now that VS 17.8 is out? Is it still similar in order of magnitude to "45 seconds"?

[Mike-E-angelo]

Thank you for your inquiry @phil-allen-msft. Unfortunately, this has only gotten worse over time. I did enable it in my solution via 17.9.0 Preview 1.1 and it now takes 2.5 minutes for a simple update.

Captured here for your review:

https://developercommunity.visualstudio.com/t/Hot-Reload-Takes-Over-Two-Minutes-to-Upd/10536525

[chsienki]

@Mike-E-angelo Damn, sorry to hear it's gotten slower again! From the trace I can see we seem to be doing a lot of Razor work which isn't expected.

Would you be able to take an ETL trace locally using PerfView? There is a counter that isn't yet enabled in the VS report a problem tool that should give us much deeper insights into what's going on with the Razor generator when we Hot Reload. If you can upload it to the VS feedback ticket we might have an easier time understanding what's going on.

PerfView instructions

• Grab the latest PerfView from here: https://github.com/microsoft/perfview/releases
• From the menu, Choose Collect -> Collect.

You can leave the settings as default except for:

• Ensure the 'Zip' and 'Merge' options are selected
• Expand the 'Advanced Options' section
• In the 'Additional Providers' section, add Microsoft-CodeAnalysis-General

Choose 'Start Collection' and perform a hot cold reload operation, same as you would with the report a problem tool.

• Click 'Stop Collection' and wait for PerfView to finish collecting.
• Attach the generated .etw.zip file to the VS Feedback bug

[LockTar]

I can confirm that it still takes a lot of time. To be honest I don't even use the feature that much anymore because it takes that long time.

[Mike-E-angelo]

To be honest I don't even use the feature that much anymore because it takes that long time.

Agreed. I disabled this feature when it became clear no effort was being made to address this for those building real-world applications. I am currently working with 48K lines of Razor here and feeling especially abandoned ATM. 😞

... and perform a hot cold reload operation ...

I appreciate the nod, @chsienki. 😅 The requested ETL is here for your review:
https://developercommunity.visualstudio.com/t/Hot-Reload-Takes-Over-Two-Minutes-to-Upd/10536525#T-N10537650

If I were to guess, my money is on #6919, as a single line of difference in my csproj currently takes over 20 seconds to compile these days. #8371 may also be contributing. Or both/other. 💥

[LockTar]

The only way I get hot reload working from VS with Blazor is by using a custom launch profile that is basically a dot net watch. I can't debug then. Found this workaround here somewhere on github.

[CommonLoon102]

@Mike-E-angelo How many projects do you have? Have you tried separating out as much components as possible? Then you can even have only a few components per project, so having a lot of projects with a few components. It might not help at all, just some brainstorming from my side. Also, try to have small files, only a few dozens of lines in a razor file. Also, have .razor files separated from .razor.cs files. So instead of having a @code{} block, use a separate file for C#.

[Mike-E-angelo]

I appreciate the assistance/thoughts/suggestions @CommonLoon102. 🙏 They are, unfortunately, more than I have gotten to date from the Razor team despite dozens of bug reports, directly appealing for any feedback to improve my situation, and even providing my solution at one point for further investigation.

As I have received zero guidance in such regard, I am of the impression that there is nothing that can be viably done ATM for my outstanding issues and that I have simply out-coded them for the time being. 😅

How many projects do you have?

159 at present. 😬

Have you tried separating out as much components as possible?

I have indeed, and this was my first inclination toward remediation. I do have feature-based projects and these do fare better with compile times. However, I have found these ultimately do not do much good as there is always work being done in the primary application/csproj in some way that gets it to compile, leading to the grief anyways.

Also, try to have small files

Nodding along with your way of thinking. I have this rocking for C# files ATM with nearly 170K lines of code over 12.5K files, averaging ~13.5 lines of code per file ATM. Razor's a different animal for me as it's newer and I haven't landed on a corresponding style that lends itself to such orientation. I'll keep this in mind going forward and see if I can improve this.

Also, have .razor files separated from .razor.cs files. So instead of having a @code{} block, use a separate file for C#.

Potentially good advice but TBH I am attached to the @code {} blocks and rather enjoy having them in one file these days. 🤔 I used to be exactly not this back in the Xaml days and preferred your suggested setup of separate code-behind. Again, I will further consider this and see how it sits with me. Thank you again for your time and thoughts.

[chsienki]

@Mike-E-angelo Thanks so much for that trace, it was extremely helpful. I found a bug where we were incorrectly re-compiling every razor file on hot reload, as opposed to just the things that changed (see #9717).

This fix should make every hot reload operation except for the first one a whole lot faster.

Note: #6919 means that the first time you hot reload in a Visual Studio session it will still be slow, but every other hot reload for the lifetime of that VS instance should then be faster. We're actively working on fixing the first edit thing, but it's a big complicated architectural issue that will take several VS releases to completely fix.

[Mike-E-angelo]

That is good news @chsienki I appreciate hearing that we're making strides here. Every little bit helps me feel better about my investments with your tech. 🙏

We're actively working on fixing the first edit thing, but it's a big complicated architectural issue that will take several VS releases to completely fix.

I hate to ask, but what the wait for the first edit thing will be like after #9717 is applied? Will it still be 2+ minutes? Or will it be the 20 seconds that I am currently encountering with #6919?

Additionally, if I understand you correctly, it sounds like it is going to take a few more years for this issue along with #6919 to be fully addressed, which is surprising, to say the least. 😭 Having more investment and focus placed on this issue would be greatly appreciated. Thank you for your continued consideration.

[chsienki]

@Mike-E-angelo Obviously can't give concrete timelines to get the re-architecting done, but it's being actively worked on. Think in the order of months, not years to get it out.

For those interested in why/what we're doing: today the Razor generator is special cased in Visual Studio; it doesn't actually run when you're typing. Instead, the razor tooling uses the Razor APIs to directly generate code and dynamically push that into Roslyn for design time. This is a historical artifact and a combination of how things used to work, and different parts of Razor being developed at different times by different teams.

On a 'full' build (i.e F5) VBCSCompiler is invoked where the generator is enabled, and nothing is special cased.

When you hot reload, an incremental build is performed to calculate the deltas that need to be applied to the process. But that incremental build is based of the design-time build where razor was suppressed. That means that on the first hot reload you perform the generator has to run from scratch and compile everything again, which as you can imagine is slow. On subsequent edits the generator caches are now full and the generator only needs to compile the things that have changed. (At least, that is true as of #9717; the bug was that we were accidentally dumping the caches between runs)

The re-architecting we're doing aims to switch design time builds to use the generator, with no special casing needed. This has several advantages, but one of them is that when you do a hot reload the first time, the caches will already be full and it only needs to do the minimal work needed to bring everything up to date, meaning it will be fast.

As you can imagine, changing the way the Roslyn and Razor in VS interact is a pretty big lift, spread out across multiple teams, and there are multiple steps we need to get done before we can even be in a position to make the main change. But the work has started and we're making progress! It'll get there, I promise.

[Mike-E-angelo]

That is much better news for my world, @chsienki. 🙏 When I hear "version" I am thinking Visual Studio 18 vs 19, etc. If I understand correctly those are taking a year each, hence my initial understanding and resulting concern. If we're talking months instead of years that would be super awesome. I understand that this is a general estimate and is subject to change.

I appreciate all the effort, and even more so for taking the time to explain things to everyone. It helps and means a lot to me, personally. Happy Holidays out there to you and the team. ⛄❄

[LockTar]

@Mike-E-angelo and @chsienki I see milestone is updated to 17.10. Is that still the planning? I hope so :-)

[chsienki]

@LockTar @Mike-E-angelo We've continued working on this during the 17.10 timeframe (see PRs titles containing Fuse and Cohosting for progress) but it seems unlikely at this point that there will be anything user visible yet.

[TiagoAntunesALS]

@chsienki Will this also fix hot reload on non razor files? we have lot of views but If a try to make a change on a .cs controller or other file that is not a view we also have the same issue.
In the Analysis.log I have this:

Document unchanged: 'file_I_Changed.cs'
Document unchanged: 'file_I_Changed.cs'
Document unchanged: 'Microsoft.CodeAnalysis.Razor.Compiler.SourceGenerators\Microsoft.NET.Sdk.Razor.SourceGenerators.RazorSourceGenerator\Views_NameOfTheView_cshtml.g.cs  
(... a o lot of those with other views)  
Capabilities required by 'file_I_Changed': Baseline

Trace.log:

Found 590 potentially changed document(s) in project  projectName.csproj
Document changed, added, or deleted: file_I_Changed.cs
Project summary for projectName.csproj
Emitting update of  projectName.csproj
Solution update 1.1 status: Ready
Module update: capabilities=[Baseline], types=[020003A4,02000A75], methods=[0600397A,06005E9B]

[chsienki]

@TiagoAntunesALS Hmm, this shouldn't be affecting cs files at all. @tmat Any thoughts on the above?

[tmat]

@TiagoAntunesALS

have the same issue.

You mean it's slow to apply updates?

The issue affects Hot Reload performance in projects containing .razor files regardless of which file you're modifying (.cs/.razor).

[TiagoAntunesALS]

@tmat Yes, slow applying changes, by .razor files are .cshtml also included? We only have those

[tmat]

Yes.

[Mike-E-angelo]

Sits through another 2-minute build due to Razor libraries

Are we ever going to have this feature? 😁😇

[chsienki]

@Mike-E-angelo We're still working on it, but it requires a pretty fundamental reworking of the Razor tooling architecture. That's an ongoing project right now. Any PRs you see mentioning Cohosting are part of that effort, and we have a pretty substantial developer investment in delivering that right now.

Nothing to try out yet, but we will absolutely ping you as soon as there is :)

[Mike-E-angelo]

Love to see that effort @chsienki and of course, I cannot help with my snarky commentary from time to time to pass+mark the time. Worth noting that I will have invested five years of my life into Blazor once October hits. 🤯 I am not going anywhere. 👍