This was originally posted on my blog.
Visual Studio 2017 has certainly been a major improvement over previous iteration of the flagship IDE; however, it isn't without its flaws.
If you are a web developer, you are probably accustomed to Google Chrome basically hogging all the RAM that your machine has (and potentially more), but today we are going to focus on another valuable resource: CPU cycles. Visual Studio 2017 has a nasty habit that can pop up occasionally and bring you and your development machine to its knees; thankfully, this post will help you fix that.
What are you doing Visual Studio?
Visual Studio 2017 can often, without reason, start throttling the CPU of the machine more than 75% without the user doing anything.
The odd part about this whole thing is that sometimes the high-CPU usage will actually return to normal levels when you actually start performing operations (i.e. scrolling within the editor, typing, etc.). This can seem incredibly frustrating to diagnose and to live with.
After reviewing through a few stack traces and chatting with a few members of the Visual Studio team, it appears that the issue itself is related to source control and how Visual Studio handles syncing itself with Git (or whatever you are using). It appears that the larger the number of files within a given project/solution, the more severe the issues can become.
Thankfully, there are a few workarounds that we can use to mitigate the issue until it is resolved.
Baby CPU come back, you can blame it all on me git.
Since we can confirm that the issue relates to the source control syncing this provides us with one of two approaches:
- Disable Source Control Syncing in Visual Studio
- Clear Out User Solution Settings
The first option, disabling the source control syncing in Visual Studio, could be an option if you are already using the command-line to handle tracking your changes and managing your workflow. The fix is relatively simple, go under Tools -> Options -> Source Control -> Current source control plug-in and set it to "None":
This will prevent Visual Studio from managing your change tracking and thus spending precious CPU cycles while idling.
For some that enjoy the comforts of Visual Studio for their source control management, the previous approach won't really be doable.
Thankfully, you can "reset" the syncing behavior for a given solution, which appears to get things back on track and at least stop Visual Studio from hemorrhaging CPU cycles while idling. To do this, find the hidden .vs folder within your solution and delete the .suo file within it:
This should help mitigate the random CPU throttling for this specific solution for the time being, however if the issue arises again, you may have to clear out this hidden file again.
You can likely expect this issue to be cleaned up within an upcoming release of Visual Studio 2017, but if this has been a thorn in your side, this should hopefully make your life a little easier.
Oldest comments (6)
There's a good chance that this is intentional. A lot of background processing (indexing, static analysis) is done when the user is idle. Once the user starts doing things, background processing is suspended for the sake of responsiveness.
Background processing can be especially taxing when working in large javascript codebases, because javascript is especially hard to analyze. You might want to try disabling some of the javascript analysis features (if it applies to you) and see if it helps with the CPU usage.
Hi Brian!
Thanks for the reply!
In this particular case, the issue was only occurring (in scenarios that I could easily reproduce) in larger codebases and projects. After some digging and research, I determined that it was in fact the source control features within Visual Studio that were constantly trying to sync with the repository for the project in the background while I was attempting to get things done.
The issue itself had apparently been documented and was slated for a fix in a recent release/update to Visual Studio, so it may have been addressed already. The mentioned workarounds are great for folks that don't have the ability to easily update their environments or are simply being hamstrung by the issue itself and it is impacting their ability to work.
Thanks for the great suggestion regarding Javascript Analysis as I know that's one that can peg CPUs as well. In general, any sort of analysis can easily be configured to run at build-time to avoid interrupting daily operation. Other potential CPU hogs include extensions, which can be an entire beast on their own.
Thanks for the comment!
Rion
Give VSCode a try?! 🚀 Just saying.
Not really helpful if you are working with pre .NET core C# codebases.
If you use ReSharper and have full Solution Analysis on it can really bring your machine to a halt if it starts doing its processing while you want to do something else.
I love ReSharper and can't do MVC development without it, though in my case I've seen it be the root of Visual Studio bringing a machine down.