x/tools/gopls: eagerly compute the workspace symbol index #52694
Comments
gopherbot
added
Tools
hyangah
added
the
gopls/performance
|
I think it might suffice to store pre-computed symbol information on disk, and load from disk rather than parsing and re-building symbol information from scratch. If that takes the initial symbol time for Kubernetes down below ~1 second, no need to pre-build symbol data. @adonovan: this may be a good proof-of-concept for on-disk indexing. |
|
Unless there's evidence that workspace symbol load time is a problem, let's not do this. I have not heard any reports of problems with the performance of workspace symbols. |
|
I've been following hoping for more activity in this but not posting to bump it. Personally I don't use workspace symbols with go and often not even current file symbols because it takes too long to load, I end up reverting to just standard find and navigate. Thought I'd add this context but understand if you don't want to invest in this area. |
|
@sheldonhull even on a relatively large repo like Kubernetes, the initial workspace symbol load takes ~1s. How large is your workspace, in terms of packages and/or files? |
|
Not that big! Might be a conflict with other stuff on my system. Is there a diagnostic output I can enable so I can give some better numbers to validate the behavior? I'll try it in codespaces + local to eliminate my machine impact and confirm. I suspected (no proof right now) that vendoring had some impact on this too in the past, but doing some A/B tests on this would let me vet this. Thanks for the quick follow-up @findleyr ! |
|
@sheldonhull we just cut a prerelease version of gopls that includes a command to dump workspace statistics. If possible, could you install this prerelease and run the |
This is a spin-off of #52602, which we're going to close as just an optiimization.
In the future, we should go one step further and populate the workspace symbol index at load time. There's a straightforward way to do this: while type-checking we always have access to the full AST of each package, before filtering. If we eagerly compute the symbol table at that time, it should be ~free.
However, I don't want to do this yet, because the cost of inheriting all these symbol handles on each generation is still too high, and our heuristic for which symbol handles to keep around is essentially "all of them", not just those that are reachable from workspace packages.
Once we have more control over snapshot data, we can re-consider this eager calculation.
The text was updated successfully, but these errors were encountered: