Huge memory usage and slow analyzers

[aldrashan]

We've got multiple big MVC projects. For some reason, the build/analyze performance varies a lot between them. Granted, the one with the biggest issues is also the one with the most files in general.

The ServiceHub.RoslynCodeAnalysisService.exe process is currently taking up 13+GB of memory for that biggest project. It's come to the point where the ctrl + space shortcut is straight up not working anymore. Visual Studio (Enterprise 2022 Version 17.8.6) also stops colouring things, as if it doesn't recognize them, although the popover when hovering over it does work. Same issue when you press ctrl + ; to suggest imports. It just loads and loads for ages and then doesn't show any results.

Please suggest things I should check and details I need to add here to help dig into the problem.

[CyrusNajmabadi]

Please see https://github.com/dotnet/roslyn/blob/main/docs/wiki/Reporting-Visual-Studio-crashes-and-performance-issues.md. We'll need a trace to determine what's going on.

Starting with https://learn.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2022 would be good. Please remember to tell it to record what you're doing as that will provide us with the necessary teachers traces.

[aldrashan]

I've ran the trace thingy the whole day, until the service was at 16GB again.

https://developercommunity.visualstudio.com/t/Roslyn-huge-memory-usage-and-slow-analyz/10582656?port=1025&fsid=0f222b3c-9454-4bd3-b458-d0b73e665410

[ToddGrun]

Hi aldrashan, I've recently been looking into our RoslynCodeAnalysis process allocation and CPU performance. It's been a while since you logged this issue, I wonder if you update to the latest and greatest VS if still experience unacceptable performance in your scenarios. If so, would it be possible for you to gather another trace/dmp and share as I might be able to find some issues that we haven't addressed yet. Note that we intentionally hold on to some memory to improve overall responsiveness, but we have found cases where we are allocating unnecessarilly or rooting and holding on to data longer than necessary.

Thanks! -- Todd

[aldrashan]

This was today while running the project. Using VS Enterprise 2022 (64 bit) 17.11.5. Not sure if it's considered "normal".

[CyrusNajmabadi]

We've got multiple big MVC projects.

Yes. It's normal that big projects use a lot of RAM.

[aldrashan]

We've got multiple big MVC projects.

Yes. It's normal that big projects use a lot of RAM.

Ofcourse, but with this amount of ram usage I wouldn’t even be able to run it on my previous laptop which only had 16GB ram.

[CyrusNajmabadi]

Ofcourse, but with this amount of ram usage I wouldn’t even be able to run it on my previous laptop which only had 16GB ram.

Large projects are going to require more resources. Can you test 17.12 and let us know where things land for you there? We can certainly try squeezing things down. But we're likely nearing the limits of what's possible. So if you do have large projects, i'd recommend a beefier machine, or breaking into small projects.

[lgsoftgit]

Hello,

We have similar problems with Visual Studio 17.11.5 - Roslyn takes 100% of RAM available. Since version 17.11.5 this "bug" exists. Version 17.11.4 is absolutely OK with this.

17.12 with .NET 9 works exactly the same. Same as bad as 17.11.5.

[CyrusNajmabadi]

Hello,

We have similar problems with Visual Studio 17.11.5 - Roslyn takes 100% of RAM available. Since version 17.11.5 this "bug" exists. Version 17.11.4 is absolutely OK with this.

17.12 with .NET 9 works exactly the same. Same as bad as 17.11.5.

How much RAM is Roslyn using?

[MrMikeJJ]

We have similar problems with Visual Studio 17.11.5 - Roslyn takes 100% of RAM available. Since version 17.11.5 this "bug" exists. Version 17.11.4 is absolutely OK with this.

Around this time I also noticed a large memory increase. I also noticed that a pile of disabled rules started being reported, so assumed it was related to that & the massive increase of warnings and messages being reported.

For further info, have it Analysis mode set to "All" and use the Roslyn and StyleCop analysers. The rules are generally disabled in a mixture of .EditorConfig & a Ruleset file. Editorconfig for disabling rules for all projects. Projects i inherited also use a ruleset to disable a chunk of rules. I use a ruleset for this, so I can have those rules managed in one place, instead of having to have 40 copies of 1 editorconfig.

Unsure because it was a while ago, but I think it was some of the rules disabled with a ruleset which got the suppression ignored.

More recently I have noticed that it looks like some disabled rules start getting reporting when the solution is opened. Before getting removed.

I also suspect some type of cache is involved as some warning stay reported after i update the editorconfig to disable them, even after a Visual Studio restart. Deleting the .vs and obj directories helps with this.

[CyrusNajmabadi]

I also suspect some type of cache is involved as some warning stay reported after i update the editorconfig to disable them, even after a Visual Studio restart.

Roslyn does not cache diagnostics. @kayle does platform ever cache diagnostics? (i doubt it, but i want to ask).

Deleting the .vs and obj directories helps with this.

This is definitely not roslyn then as we do not use those directories. Maybe another extension you have installed.

[CyrusNajmabadi]

Around this time I also noticed a large memory increase. I also noticed that a pile of disabled rules started being reported

You may have misconfigured things. @JoeRobich to add information on this.

[kayle]

Roslyn does not cache diagnostics. @kayle does platform ever cache diagnostics? (i doubt it, but i want to ask).

Platform doesn't cache diagnostics either. I'm guessing, but I think it would be project system if things persist across restarting VS.

[JoeRobich]

For further info, have it Analysis mode set to "All" and use the Roslyn and StyleCop analysers.

@MrMikeJJ If you are using the 9.0.100 SDK there is a change where CodeStyle analyzers get updated defaults based on the <AnalysisMode>. There are two options for handling this, you can set individual diagnostics to a lower severity, or you can change the defaults the SDK is applying to CodeStyle.

A. To change the severity of the newly reported IDE diagnostics:

1. Use an .editorconfig
2. Set each of the diagnostics to the desired severity

   [*.cs]
   dotnet_diagnostic.{IDExxxx}.severity = silent

B. To keep your enhanced defaults for code analysis while lowering the code style defaults to their pre-.NET 9.0 state, do the following:

1. If your solution/project is setting the <AnalysisMode> via the <AnalysisLevel> suffix (i.e. <AnalysisLevel>{level}-{mode}</AnalysisLevel>), then you should separate them into separate properties.
2. Set <AnalysisModeStyle> to default (<AnalysisModeStyle>default</AnalysisModeStyle>).

   <PropertyGroup>
   <AnalysisLevel>latest</AnalysisLevel>
   <AnalysisMode>all</AnalysisMode>
   <AnalysisModeStyle>default</AnalysisModeStyle>
   </PropertyGroup>

[lgsoftgit]

Hello, We have similar problems with Visual Studio 17.11.5 - Roslyn takes 100% of RAM available. Since version 17.11.5 this "bug" exists. Version 17.11.4 is absolutely OK with this. 17.12 with .NET 9 works exactly the same. Same as bad as 17.11.5.

How much RAM is Roslyn using?

Around 16GB+ - it takes RAM to 99% of overall value. VS 2022 is unusable.

[CyrusNajmabadi]

Please file an issue with visual studio. You'll be able to record a report which will include the traces we need to see what's wrong @lgsoftgit