x/tools/gopls: parse dependency ASTs in full mode #38278
Labels
FrozenDueToAge
gopls/performance
Issues related to gopls performance (CPU, memory, etc).
gopls
Issues related to the Go language server, gopls.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
Comments
stamblerre
added
the
NeedsInvestigation
gopherbot
added
Tools
|
A while back, @findleyr and I discussed a related topic which might allow us to get accurate analysis results for dependencies without the memory cost of keeping full ASTs in memory. Rob suggested that we could try pruning the ASTs after analysis runs, so the facts generated by analyses would be correct, but we would not pay the cost of keeping the full ASTs in memory. |
stamblerre
changed the title
findleyr
added
the
gopls/performance
|
any progress for now? |
|
This will be made obsolete by #57987. We are already producing complete analysis results (in master, not yet released). |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We really only use dependency ASTs for finding definitions and documentation, and we can avoid extra work and AST traversal by precomputing what we need. In most cases, dependencies are only type-checked once. I propose this alternative:
PackageHandles, one for workspace packages (PackageHandle) and one for dependencies (ExportedPackageHandle).PackageHandleremains the same as it is now, whileExportedPackageHandledoes not contain references to the package'sParseGoHandles. Rather, it contains a pre-computed table of information that can be used for various features. My guess is that it will be a table oftoken.Pos-> documentation, but I'm sure I missed things./cc @heschik @ianthehat
The text was updated successfully, but these errors were encountered: