-
Notifications
You must be signed in to change notification settings - Fork 417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Go to Symbol in Workspace…" is slow with moderately sized solution containing only C# projects #1243
Comments
IIRC Problem is in vscode rendering thousands of symbols in the ui after server returns them, not on the server side. |
Interesting. I was only judging by OmniSharp output log because I see a significant delay after "/findsymbols" request printed and before the response appears. In any case I would argue that "/findsymbols" processing should be limited in both time and the amount of data it is allowed to return. A user IMO is unlikely to just scroll through thousands of entries and s/he is more likely to continue typing the filter to narrow the result to only few entries. |
BTW, this issue I opened sounds like a dupe of dotnet/vscode-csharp#1808 |
Yup that's it. I remember I just modified "workspaceSymbolProvider.js" manually so I never pass on insanely big symbol lists to vscode, and it solved all the problems. Wanted to make a PR but it just flew over my head. |
This is definitely could be a good quick fix, but long term IMO ideally each supported file system (MSBuild, Cake, etc) limits as well how many items it attempts to discover and send back with /findsymbols response. |
With the latest changes omnisharp.maxFindSymbolsItems is set to 1000 by default which should address this issue. omnisharp.minFindSymbolsFilterLength should probably be set to 1 or 2 for bigger codebases as well. |
REPRO: I opened a solution in VS Code containing 68 C# projects (according to the response for "/projects" request in OmniSharp output log). Once all projects were loaded (took about a minute), I pressed Ctrl-T and had to wait for at least 15 seconds for the list to be populated. This happened every time Ctrl-T is pressed - not only the first time. Additionally, typing a single character freezes the list again for few seconds which makes the feature only marginally useful in this case.
EXPECTED: IMO OmniSharp could:
The text was updated successfully, but these errors were encountered: