workspace symbols: only include symbols defined in the current workspace

[ewen-lbh]

Is your feature request related to a problem? Please describe. The "Go to symbol in Workspace…" feature performs a search on all symbols available to the workspace, even those defined in modules declared as dependencies in go.mod. This makes the search take at least several seconds, which is way too much for supposedly quick navigation. Jumping to symbols that you didn't defined is rarely useful anyway. Sometimes, symbols from other modules are sorted before symbols that you want to jump to, since they match the query better, forcing you to look through the results list to find what you're looking for, and using arrows to jump to it.

Describe the solution you'd like A setting (or even just outright changing it) that limits the search space to symbols defined in the workspace's files.

Describe alternatives you've considered N/A

Additional context An example: The BuildMetadata struct entry is buried under more than ten entries that pertain to Go's standard library

[findleyr]

Hi, thanks for filing this issue. This has come up before, and we feel that it is helpful to be able to jump to symbols in the standard library or in an import. It's a feature that I use all the time.

gopls does prioritize results in the current workspace over results outside of the workspace. Unfortunately, VS Code mangles the sorting. There is an open issue for this against VS Code: https://github.com/microsoft/vscode/issues/98125.

gopls already has a lot of configuration, and we'd like to avoid adding additional configuration, especially if it just to work around a vs code limitation. If a large number of users disagree we can re-evaluate, but in the meantime this is unlikely to be changed.

I'll leave this open for a little while to allow for discussion.

[ewen-lbh]

This has come up before, and we feel that it is helpful to be able to jump to symbols in the standard library or in an import. It's a feature that I use all the time.

While I do understand that stdlib jumps can be useful, it also is an issue when this results in upwards of multiple entire seconds of waiting for symbols to show up. I wonder if it would be possible to do a first "quick pass" to populate suggestions with just workspace symbols, and then do the more intensive analysis of all dependencies. This might not be possible with current vscode APIs, though, it looks like the entire symbols array has to be provided in one go, but I'm no expert in that field.

[findleyr]

@ewen-lbh we have spent some time recently optimizing the initial workspace symbols request. In Kubernetes, for example, we have optimized it from ~5s down to ~500ms. What is your gopls version? If it is >= v0.9.0, could you share more information about the size of your workspace?

Once the first symbol request is complete, subsequent requests should be very fast. Is that your experience?

The workspace/symbol RPC does support partial results, though we do not use this feature as for other LSP clients the sorting of results matters, and generally the entire request should be very fast.

[ewen-lbh]

After upgrading to the latest version of gopls (v0.9.1), and testing for a few days, I found the experience to be kind of hit or miss: on some days, the first lookup was quite fast, and subsequent lookups were considerably faster. But on some other days, lookups took around 7s, and subsequent lookups were just as slow. I'll code on this Go project for a few more days to gather more data.

Here is some information that might be relevant to my workspace size: I have 6584 lines of Go code spread across 36 files, which are part of three different repositories (one of them does not contain Go code). These three repositories are available on Github:

• https://github.com/ewen-lbh/portfolio
• https://github.com/ortfo/mk
• https://github.com/ortfo/db

[findleyr]

Here is some information that might be relevant to my workspace size: I have 6584 lines of Go code spread across 36 files, which are part of three different repositories (one of them does not contain Go code). These three repositories are available on Github:

For the record that is tiny. We regularly measure the initial workspace symbols request on Kubernetes (which has ~25k files and ~2500 packages), and the initial request takes ~600ms, with subsequent requests taking ~60ms.

It seems that there may be something else going on here, something that is blocking the workspace symbols request from being handled in the first place. Would you be able to capture LSP logs on a day when you encounter this slowness?

Instructions for how to capture logs are here: https://github.com/golang/vscode-go/blob/master/docs/troubleshooting.md#collect-gopls-information

[ewen-lbh]

For the record that is tiny

Yes, I expected this. A one-dev side project vs Kubernetes... Not even comparable.

I'll enable -rpc.trace (and also increase verbosity), and report back if I encounter slowness again.

[hyangah]

@ewen-lbh How is it going? Have you managed to capture a log that exhibits slowness?

[ewen-lbh]

@ewen-lbh How is it going? Have you managed to capture a log that exhibits slowness?

I'm currently on vacation, I'll get back to this issue once I return, around August the 15th

[hyangah]

@ewen-lbh gopls v0.12.0 (to be released) will have a new setting symbolScope

Setting this to workspace will limit the search scope as you wanted.

On the other hand, gopls v0.12.0 also includes significant changes in how gopls indexes symbols. I think that will also help workspace symbol search performance even when the scope includes dependencies.