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.
CodeProject
