ServiceHub.RoslynCodeAnalysisService32.exe High CPU Usage when *editing* code

[SheaCodes]

Version Used: Visual Studio 2017

Steps to Reproduce:

1. Open a solution (preferably large)
2. Type one letter
3. Watch Task Manager

Expected Behavior: Visual Studio does not compile/analyze my solution until I explicitly request compilation.

Actual Behavior: Visual Studio appears to be compiling/analyzing my solution which consumes CPU cycles as I continue to write code.

[yberstad]

I have the exact same issue:

[sharwell]

Please don't take my questions as an attempt to discredit your issue, as I definitely do value work to improve the situation taken at face value. :smile:

I'm curious if you have any suggestions for specific scenarios we should be optimizing for that would help you in particular. For example:

• Does the increased CPU usage appear to be causing Visual Studio other programs to perform poorly in some way (e.g. typing responsiveness)?
• How big is the project you're working in? Does the situation seem related to project size?
• If the problem occurs more frequently in particular solutions, do you happen to work on an example one which is open source?
• In a hypothetical situation where you had to choose between reduced background CPU usage (like you are observing) and reduced time to obtain answers from features like Navigate To or Find All References, how would you approach a decision regarding finding a balance between the two?

Is there any other specific benefit you're hoping to bring about by reducing the CPU usage here, that could help with the long-term story surrounding why improvements in this area are important to customers? This could be general things, or even things specific to you and the way you work.

[SheaCodes]

Thank you for your response.

• While the CPU usage does appear to be at low priority (typing responsiveness is not affected), it nevertheless causes my laptop CPU fan to run almost constantly when I'm coding, and my left hand becomes uncomfortably hot because the CPU in my laptop is located underneath where that hand rests. Also, the poor environment :)
• The solution I am working on contains 5 projects totaling 193,000 lines of code. I don't have any quantitative data on this but since a spike in CPU usage is not noticeable on a brand new Visual Studio 2017 solution, I assumed that CPU usage increases proportionally to lines of code in the solution.
• I do not have an open source example (do you have an example of a similarly-sized open source solution that does not experience this behavior?). The issue does occur on all of the 20-25 solutions I frequently work on in our company (all of which share one at least one common project containing 50,000 lines of code).
• I am definitely willing to accept background CPU usage in return for code navigation as I have been using ReSharper since 2005. I do not use the built-in Visual Studio equivalent features. ReSharper provides the option to "replace Visual Studio refactorings with its own", which I have enabled. I'm assuming ReSharper incurs a CPU hit also, but I can not detect it in Task Manager (perhaps they're able to do the work more efficiently or are doing less work, that is outside my area of knowledge). Either way, unless ReSharper is sharing the results of ServiceHub.RoslynCodeAnalysisService32.exe, it feels to me like that is being done without any benefit to me and without any way to disable it. It feels like ReSharper's full solution analysis feature but without the option to turn it off. It is particularly invasive because of the amount of CPU used.

I must profess that the line between what is provided by Visual Studio and what is provided ReSharper is sometimes somewhat blurry to me, but to the best of my knowledge, all of the code refactorings and code analysis I leverage is provided by ReSharper.

Additionally, it appears as though solutions which are open in the background but share a common project will undergo the same analysis when a code a file in a common project is saved. My preferred workflow is to have multiple solutions open but I have chosen not to do this anymore due to excessive CPU usage.

[Pilchie]

Tagging @heejaechang, @mavasani, and @panopticoncentral, @CyrusNajmabadi

Can you also answer:

1. Do you have Code Lens enabled?
2. Do you have "Full solution analysis" (from Tools\Options\Text Editor\C#\Advanced) enabled?
3. Do you have Live Unit Testing enabled?

If you do have any/all of those enabled, can you try disabling them to see if one of them is a particular offender? Those are the 3 things that I know that we run in that process so far...

[SheaCodes]

Ah.

2. I had full solution analysis enabled.

Thank you for your help.

[Z1ni]

I had the same problem until I disabled Code Lens. Very high CPU usage and not so big solution file. I think this issue should be kept open as the problem still persists, even though there are workarounds. I'd still like to use Code Lens.

[sharwell]

@Z1ni If you open your own issue, then you'll be able to decide when it's resolved (or not). This issue was closed by the author because one specific situation was resolved to their satisfaction, and my hope would be to do the same for you. 👍

[Z1ni]

@sharwell If I would open my own issue, it would be a duplicate of this. I don't see why there should be a duplicate when this issue has workarounds listed, labels set and devs tagged.

[sharwell]

@Z1ni The first thing I'd like to try is narrowing down which CodeLens feature(s) are most responsible for the situation you've observed. Can you start by disabling everything except Show References (which can't be disabled) and see if the situation improves? If you notice a big improvement, then it means one of the optional features was contributing to what you observed. In that case, you could work through the four categories in this image and try to gauge the performance relative to the case where only Show References is enabled.

[mvestergaard]

I'm not quite sure why this issue is closed as it is still quite prominent. It should be noted that the project I'm working on is fairly large, and uses StyleCop.Analyzers on all projects.

However I find that just placing a single space in a file kicks off this big spike in CPU usage. It peaks at around 80%.

I know nothing of the internals of the code analyser, but I find it weird that a single space in a file would require analysis of the entire project.

Using VS2017 update 2.

[heejaechang]

@mvestergaard since we don't restrict what analyzer can do, also since engine doesn't know what each analyzer wants to produce, we can't arbitrarily skip running analyzers on changes. whatever change it is, if user changed source, we had to run analyzers.

some of our internal analyzers we know specifically what it does, so for those, we can optimize to skip analysis on such change (space changes), but there are style analyzer which even care about space changes, so we had to run analyzers.

if High CPU is something that bothers you, you can turn full solution analysis off (Tools->Options->TextEditor->C#->Advanced).

[mvestergaard]

@heejaechang Full solution analysis is off already.

[heejaechang]

@mvestergaard then the CPU is not due to analyzer then. probably due to code lens. can you turn off code lens?

if you have any solution wide features on that runs automatically on source changes, it will use high CPU if solution is big.

[mvestergaard]

@heejaechang Odd, I'm not seeing anywhere near the CPU usage I saw earlier today right now. So it might have fixed itself with a restart of VS.

I'll try disabling codelens if the issue appears again. Thanks for the replies.

[rdstevens]

Yes! Disable CodeLens and my CPU usage drops, Visual Studio responds to key presses in a timely fashion, intellisense is speedy once again, and my laptop battery survives for extra hours!

It's a shame: I really like CodeLens.

Perhaps there should be an option to automatically disable when running on battery power?

[creationw]

I had the exactly same result. Waiting Visual Studio team to address this issue.

[heejaechang]

@creationw the process run as low priority to do solution wide features. so it is expected to use high CPU if machine is Idle.

if you don't like high CPU usages, you should turn off those solution wide features that are expensive to run such as code lens, live unit testing, source based test discovery, full solution analysis.

if you believe the process still uses a lot of CPU time even after you turned off all ambient solution wide features (features that just run if you machine is idle), can you send us traces using VS feedbacks so that we can take a look what is taking the CPU?

[rocifier]

Hi, I have been experiencing the same problem in VS2017 recently, but in my case the performance degrades so much that typing and mouse clicks are affected - they end up being completely misjudged by the IDE. The problem gets worse over time until my mouse freezes for minutes at a time and then forever, requiring a hard reset of my machine. I have a perfview capture of one of the mouse freezing spikes and it's almost entirely inside ServiceHub.RoslynCodeAnalysisService32.exe.

I am going to try some of the suggestions here to narrow down the features and report back.

[sharwell]

@rocifier Your best bet is to follow the steps in https://aka.ms/reportPerf and reference @sharwell in the description of the issue.

[rocifier]

Thanks, I just submitted it now. My zipped .etl was hundreds of megs but it sent almost instantaneously. @sharwell Want to do me a favor and check the full trace sent through? I forgot to mention you in the report description XD. EDIT: The report popped up here: https://developercommunity.visualstudio.com/content/problem/482398/servicehubroslyncodeanalysisservice32exe-high-cpu.html

[sharwell]

@sadeghitk can you file a new issue for that?

[sadeghitk]

Will do.

[BobT2022]

Just to add my own similar experience when building using VS2022 17.4.2 - the build process and VBCSCompiler.exe specifically goes nuts if it finds a CS file that's quite large; ~30mb in my case due to a particular unit test having a large Base64 encoded string literal used for capacity/load testing. Seems the sheer size of the CS file, despite the bulk being a string literal used for testing purposes caused the compiler to never end (in retrospect the content should have been loaded from an external file but at the time of writing the test it worked perfectly well as-is).

[mavasani]

Just to add my own similar experience when building using VS2022 17.4.2 - the build process and VBCSCompiler.exe specifically goes nuts if it finds a CS file that's quite large; ~30mb in my case due to a particular unit test having a large Base64 encoded string literal used for capacity/load testing. Seems the sheer size of the CS file, despite the bulk being a string literal used for testing purposes caused the compiler to never end (in retrospect the content should have been loaded from an external file but at the time of writing the test it worked perfectly well as-is).

@BobT2022 There was a high CPU usage regression in 17.4.1 in background analysis, that should have been fixed in 17.4.3. If you are still seeing it in 17.4.3, it is likely a different issue and we request you to file a feedback ticket with a performance trace to help us investigate it. Thanks!

[BobT2022]

Just to add my own similar experience when building using VS2022 17.4.2 - the build process and VBCSCompiler.exe specifically goes nuts if it finds a CS file that's quite large; ~30mb in my case due to a particular unit test having a large Base64 encoded string literal used for capacity/load testing. Seems the sheer size of the CS file, despite the bulk being a string literal used for testing purposes caused the compiler to never end (in retrospect the content should have been loaded from an external file but at the time of writing the test it worked perfectly well as-is).

@BobT2022 There was a high CPU usage regression in 17.4.1 in background analysis, that should have been fixed in 17.4.3. If you are still seeing it in 17.4.3, it is likely a different issue and we request you to file a feedback ticket with a performance trace to help us investigate it. Thanks!

I've tried using the Report a Problem tool in VS2022 17.4.2 however my dev environments are locked down so that mechanism doesn't start - I'll try and repro the issue elsewhere with the required internet access as a separate issue (the repro itself is pretty much a matter of creating a .NET 7 unit test project with a single test method which asserts a string variable set to a ~30MB Base64 encoded sample PDF (in my case) isn't null - the issue being the build process hangs at the analysis stage.

[CyrusNajmabadi]

@BobT2022 you may consider: https://github.com/dotnet/roslyn/blob/main/docs/wiki/Recording-performance-traces-with-PerfView.md

For now though, I'd highly recommend moving your string literal to just be a resource. We will often make changes that are fine for 99.999% of users but which may have a problem for pathological cases that one file in a billion have.

That could easily have impacted you here.

[CyrusNajmabadi]

Also, this issue is closed as we fixed the problem that was being reported here. You should open a new issues for your unique case as it is not related to this one. Thanks!