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 https://github.com/dotnet/aspnetcore/issues/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: https://github.com/dotnet/sdk/pull/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]

https://github.com/dotnet/sdk/pull/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: https://github.com/dotnet/razor-tooling/issues/5697#issuecomment-1080942033)

[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. https://github.com/dotnet/sdk/pull/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. 🙏

[Mike-E-angelo]

Any update with this issue, by chance? I have yet to use Hot Reload once for my Blazor solution. Well, outside of it taking a minute or so for it to work and reporting it here as a bug. :P

[zoinkydoink]

It takes mine ~28 seconds to update on a relatively small blazor project with some Telerik controls.

I am using a 10core, 64gb machine, I am using .NET 7.0 as well.

I am using dotnet watch run / dotnet watch The workaround posted does nothing for me

It actually a lot faster if i Ctrl+C and dotnet watch run / dotnet watch again

[Drammy]

What is the latest on this please?

I love the tech but it's so disheartening when fixing a typo in an html class and then having to wait over a minute for that change to appear on the UI. It just destroys productivity.

Does anyone have any workarounds or am I best to abandon hot reload and just rebuild and retest every now and again?

dotnet watch ⌚ File changed: ./.Client/Pages/Activity.razor.

<LONG WAIT>

dotnet watch ⌚ Received 1 from browser in [Count: 1, MessageType: Binary, EndOfMessage: True].
dotnet watch ⌚ Received successful apply from delta applier.
dotnet watch 🔥 Hot reload of changes succeeded.
dotnet watch 🔥 Hot reload change handled in 6212834.683ms.

[DamianEdwards]

@Drammy @zoinkydoink @Mike-E-angelo and others experiencing very long (>20s) hot reload times: are you all working on Blazor WebAssembly projects? Has anybody experienced these very long times in Visual Studio when working on Blazor Server projects?

[Mike-E-angelo]

Blazor server here, @DamianEdwards. I have yet to ever see Hot Reload work once in a viable way while in Visual Studio. FWIW I am also the one who reported the original issue on developercommunity under a previous account, and this should reflect a Blazor server project as well.

[zoinkydoink]

@DamianEdwards I am using Blazor Server side, I tracked down my issue further. It seems that having about 20-30 controls (html and mixed with telerik blazor) was actually the issue. If i have a blank blazor page with minimal stuff on it then hot reload is instant. so it has something to do with having too many elements on the page.

I gave up using hot reload on this page because the next thing i needed to do was redesign my page with more components than just straight up html/telerik controls directly on the page.

All in all, do a lot of testing with many controls and figure out why that is an issue.

Thanks for following up though

[Drammy]

@Drammy @zoinkydoink @Mike-E-angelo and others experiencing very long (>20s) hot reload times: are you all working on Blazor WebAssembly projects? Has anybody experienced these very long times in Visual Studio when working on Blazor Server projects?

@DamianEdwards We're developing Blazor web assembly using Rider on a Mac, so just the dotnet command line tools for us.

[Drammy]

For what its worth I've refactored the large page component down into numerous smaller components and the hot reload performance is much better.

[CommonLoon102]

You could also try moving out components to separate projects, even to multiple projects. And only have the pages in one project which just using the components. I'm not sure if it would help on the performance, but worth a try.

[tmat]

See also: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1465553

[Drammy]

See also: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1465553

@tmat this appears to be a private link

[dragnilar]

I have been having the same problem with dotnet watch / hot reload (no VS involved) as @zoinkydoink. Specifically, it is with a page that has many DevExpress components. Unfortunately, as with zoinky, it is faster to just restart dotnet watch / debugging than it is to wait for hot reload to make its change. Sometimes it can take over a minute for hot reload to make a change...

@chsienki Question - you have this set to 17.9 planning, does that mean any potential changes will be for both VS and dotnet CLI or will it be just for VS?

[Mike-E-angelo]

Wonder if https://github.com/dotnet/razor/pull/9214 will finally make this feature viable for my solution 🤔

[densen2014]

Hotreload is really difficult to use, especially for Blazor projects. The latest version of Winform also difficult to use.

[h2ls]

Hotreload's performance is really poor

[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 https://github.com/dotnet/razor/pull/9717).

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

Note: https://github.com/dotnet/razor/issues/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]