Skip to content
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

Closed
dmgonch opened this issue Jul 10, 2018 · 6 comments

Comments

@dmgonch
Copy link
Contributor

dmgonch commented Jul 10, 2018

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:

  • Cache results of recently issued "/findsymbols" requests.
  • Apply a strict timeout when processing "/findsymbols" requests and return cached or partial or simply empty result when the timeout is reached.
@SirIntruder
Copy link
Contributor

IIRC Problem is in vscode rendering thousands of symbols in the ui after server returns them, not on the server side.

@dmgonch
Copy link
Contributor Author

dmgonch commented Jul 10, 2018

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.

@dmgonch
Copy link
Contributor Author

dmgonch commented Jul 10, 2018

BTW, this issue I opened sounds like a dupe of dotnet/vscode-csharp#1808

@SirIntruder
Copy link
Contributor

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.

@dmgonch
Copy link
Contributor Author

dmgonch commented Jul 11, 2018

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.

@dmgonch
Copy link
Contributor Author

dmgonch commented Sep 22, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants