Should we limit maximum amount of symbols returned by workspaceSymbomProvider?

[SirIntruder]

VS 17.2, c# 1.12, WIn 10

My current workspace has >30.000 symbols, which make vscode symbol search almost unusable.
Problem is that when search term is empty string, all symbols are returned, and vscode dropdown UI takes FOREVER with inserting 30.000 items in the dropdown UI.

I posted this issue to vscode repo:
microsoft/vscode#36941

I later saw somobody had a similar issue with vscode with IIRC PHP, half a year ago. Sombody said another language ext solved the issue by capping resulting symbol list, which makes sense since nobody wants to scroll in the dropdown with tens of thousands of elements - they will narrow down the search until item they are looking for appears close to the top.

Which you can't do in big workspaces currently, since search is so unresponsive.

Another thing to consider is to handle case when search term is empty string specifically, since that's the one that is causing most problems. Personaly, I quick fixed the problem for myself by just returning empty list when search terms are empty.

[rchande]

@DustinCampbell Do you have a sense of whether people commonly use ctrl-t to bring up all of the symbols in their solution and browse the list without typing anything more? Currently, we return all of the symbols in no particular order, so this isn't an especially great experience. Could we simply not search if the search string is empty?

[rchande]

We could also just choose a really small limit for the empty search string case.

[DustinCampbell]

@rchande : I have no idea.

[DustinCampbell]

Note that, in Visual Studio we don't produce a list until the first two characters are typed.

[SirIntruder]

Capping resulting array before returning is kind of a must have currently, since vscode freezes completely when processing large array.

Not requesting all workspace symbol is also good IMHO, but not as critical, since it "only" takes a couple of seconds and is not a blocking call.

Anyway, if we want to fix this, it should be pretty symple, here is setup that worked for me:

    provideWorkspaceSymbols(search, token) {
	if (search == "") return null;
        return serverUtils.findSymbols(this._server, { Filter: search, FileName: '' }, token).then(res => {
            if (res && Array.isArray(res.QuickFixes)) {
                return res.QuickFixes.slice(0, 100).map(OmnisharpWorkspaceSymbolProvider._asSymbolInformation);
            }
        });
    }

btw, not that I could use symbol search I was going to report fuzzy search not finding "DummyController" when searching for "Controller", but it is fixed the same day in 13.0beta4, so kudos for that 😆

[filipw]

I think in this case the cap should be on the server side (perhaps the filter object can have a Limit property allowing the caller to set the cap) and it would benefit other OmniSharp clients too.

But yeah, I don't think it's reasonable to return hundreds of results

[akshita31]

This is fixed by #2487