[Feature Request] Background analysis for open document only

lonix1 commented 7 months ago

Is your feature request related to a problem? Please describe.

VSCode has become increasingly slow due to background code analysis; after every few updates something changes and it becomes even slower than before. It's even slower than the previous O# extension.

When analysis and building occur at the same time my machine becomes completely unusable, it saturates all cores and all memory.

This is the case for "dotnet.backgroundAnalysis.analyzerDiagnosticsScope" when set to openFiles and fullSolution. Setting it to none is obviously not a solution.

Describe the solution you would like

Please add an option to analyse the current file only, e.g. currentFile. One must take into account that the user could be switching between many files quickly, but one could debounce that easily.

If that is too tricky, an alternative is to analyse files as they're opened (and stay open for 5 seconds, say, or only after an edit is made) and remember the last "n" files. That means only the files the user is interested in, and actively working on, would be actively analysed. The others would be analysed the normal way during building.

Applicable Scenarios

All C# projects.

Describe alternatives you've considered

There are no alternatives. VSCode is fast for large projects in all languages, except c#.

Additional context

What would be really nice is to set a limit to the amount of RAM or the number of cores that the analyser is allowed to use. I don't know if that's possible.
It would be very helpful to have an optional status bar message showing when analysis is taking place (like O#) had; that would make it clear what is the cause of slowdowns

dibarbet commented 7 months ago

@lonix1 Trying to understand if we just have a perf issue with open file analysis that we need to fix, or if we really need a current file only option.

Do you have a rough idea of how many files you have open? Are they files spanning multiple projects?
It could be a specific analyzer causing things to slow down. Could you try turning off analyzers (but leaving on compiler analysis)? Change dotnet.backgroundAnalysis.analyzerDiagnosticsScope to none, but leave dotnet.backgroundAnalysis.compilerDiagnosticsScope as openFiles does the perf improve?

I'll also get back to you with instructions on collecting a perf trace which would be helpful here.

For a current file only option we will likely need some changes on the VSCode / LSP side. Currently LSP does not tell us which file is active - we only get requests for all open files.

It would be very helpful to have an optional status bar message showing when analysis is taking place (like O#) had; that would make it clear what is the cause of slowdowns

This is an interesting suggestion. Will have to take a look to see if this is something we can do.

lonix1 commented 7 months ago

1. Do you have a rough idea of how many files you have open?  Are they files spanning multiple projects?

Somewhat noticeable for 10+ files open, and definitely for 20+. That seems like a large number but with the ever growing complexity of modern systems it's not - sometimes I need to be able to have that many open. And this is not an issue in other languages, which is important to remember.

Are they files spanning multiple projects?

Yes, the workspace has about 5 interrelated projects, and test projects too. Maybe that contributes to the issue? Keep in mind that is normal for large workspaces.

Note this is for a monorepo. I wonder what the perf would be like for a workspace with microservices projects.

2. Change `dotnet.backgroundAnalysis.analyzerDiagnosticsScope` to `none`, but leave `dotnet.backgroundAnalysis.compilerDiagnosticsScope` as `openFiles` does the perf improve?

I'll do that for a while and report back, thanks!

It would be very helpful to have an optional status bar message showing when analysis is taking place (like O#) had; that would make it clear what is the cause of slowdowns This is an interesting suggestion. Will have to take a look to see if this is something we can do.

:+1:

lonix1 commented 7 months ago

Better perf, but I suppose that is to be expected given that analysers are off.

Hopefully in time other people will comment here about their experience - so we can diagnose the underlying issue(s). Feel free to close until then.

dotnet / vscode-csharp