VS 2026 does not respect SolutionBackgroundAnalysis setting.

[majocha]

I noticed surprisingly high CPU and memory use when opening F# solutions.

Turns out not only VS 2026 does not respect the solution crawler setting:

What it does is not a crawl, it is a speedrun. For example, when I open a solution with no F# editors open, the checker should be idle. Instead, I get something like this:

All the analyzers, diagnostics, fixes running at break neck pace on the whole solution.

When trying to edit files, the churn is endless, causing long GC pauses.

Another thing, this does not happen in experimental instance, just with the installed product.

[majocha]

ETA: Turns out it is some hidden setting. As soon as I imported settings from the installed version to the experimental instance, it started happening in the experimental instance, too.

[T-Gro]

UnusedOpens and SimplifyNames are separate analyzers managed from the F# options - are they enabled for you?
Even when their entry is logged, they do a no-op if they are disabled.

[majocha]

Even GetDiagnostics is called for everything at once:

In fact looks like the logic goes like this, GetDiagnostics first, then other analyzers. If I view the actual checker activity, it really does typecheck EVERYTHING.

[majocha]

I did an experiment now, and forced whole solution analysis (Alt + F11) on VisualFSharp.sln. After good few minutes, the churn stops. So this is not an endless loop at least.

Then I opened FSharpInlineHintsService.fs which is the very last file in FSharp.Editor. Each keystroke in the file causes GetDiagnostics and other analyzers on the whole project. So this possibly goes via CPS -> Roslyn workspace -> Roslyn project invalidated -> forced typechecks disregarding the background scope setting.

[T-Gro]

I will check if anything changed in our dependencies for the VS2026 migration.
Those are "pull" diagnostics, so the F# extension is being actively asked for it.

[T-Gro]

Possible problem:
I can see the solution crawler setting is global., not per language
https://github.com/dotnet/roslyn/blame/9e84ffd96d875c7db87046941fec0d80a15b8287/src/VisualStudio/Core/Def/Options/VisualStudioOptionStorage.cs#L364

There were some reverts to it (SolutionCrawlerRegistrationService.EnableSolutionCrawler).

It is probably a long shot, but can you try disabling the related C# options ?
(I just checked and I do have C# options at "Entire solution" as well)

[majocha]

Yes I tried this without success:

Also I now don't think this goes through solution crawler at all. ( I suspect the crawler is used only for TypeScript (?) ) We export DiagnosticAnalyzers and they are hooked up in Roslyn with hardcoded priorities, that where my investigation hits a dead end:

https://github.com/search?q=repo%3Adotnet%2Froslyn%20%5BDiagnosticAnalyzer(LanguageNames.FSharp)%5D&type=code

[majocha]

So, I just built Roslyn and put a red dot in FSharpDocumentDiagnosticAnalyzer to see who's calling it.

Turns out there are two things. First, on each keystroke / document change we go through here: https://github.com/dotnet/roslyn/blob/198cace8c95fb7263c182dada5a75dbab2cb8f06/src/Features/Core/Portable/Diagnostics/Service/DiagnosticAnalyzerService_ComputeDiagnosticAnalysisResults.cs#L35
but this requests diagnostics for the whole project each time. Does not look optimal.

Second, the behavior on solution load does not reproduce in debug mode. But it seems the request handler does look at "{dotnet_enable_solution_crawler}" and the setting is true:

https://github.com/dotnet/roslyn/blob/198cace8c95fb7263c182dada5a75dbab2cb8f06/src/LanguageServer/Protocol/Handler/Diagnostics/AbstractPullDiagnosticHandler.cs#L106-L108

The comment here suggests there is no way to disable solution crawler. hmm...

[majocha]

This task ends up executing on solution load:
https://github.com/dotnet/roslyn/blob/198cace8c95fb7263c182dada5a75dbab2cb8f06/src/Features/Core/Portable/Diagnostics/Service/DiagnosticAnalyzerService_ComputeDiagnosticAnalysisResults.cs#L110

So the analysis is performed with project granularity, even if only one source file is open.

[majocha]

Luckily this turned out waaaaay simpler to fix than I thought. I'll post a fix soon.