x/tools/gopls: long initial workspace load durations for workspace with many packages #69523
Labels
gopls/metadata
Issues related to metadata loading in gopls
gopls
Issues related to the Go language server, gopls.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls version
go env
What did you do?
My organization within the company is responsible for maintaining a large Go monorepo (~20k packages). In this monorepo, all packages fall under 1 Go module.
For the most part, we run a fairly off-the-shelf gopls setup without any customization of note. This is what our stats look like (from
bea7373d8a8268c2e3a260c1b8d41f96c4f7489e
):What did you see happen?
The experience of using gopls is good (i.e. rpcs like jump-to-definition, refactor symbol, etc. are fast) once initial workspace load has occurred, but initial workspace loads are a poor experience for our users. This poor experience is owed to two behaviors:
Firstly, initial workspace loads (IWLs) are slow. This is partially owed to the performance of the expensive upfront
go list
call itself:…but the majority of the time is spent on calling
packages.Load
on all of the packages thatgo list
returns.Secondly, because IWLs are blocking and VSCode waits on code actions before the IDE is able to save files, users are unable to save files/exit their IDEs/etc:
…while IWL is incomplete. This is partially a corollary of the first issue. While it is true that making code actions non-blocking for saves would fix this UX issue, if IWL were fast, this UX issue would not be perceived by users in the first place.
We have dipped our toes in trying to patch this behavior. For example, an early attempt at hacking around this behavior (on a
v1.16.1
base) no-ops the initialization routine altogether, relying solely on gopls loading in package data as files are manually opened by the user. As expected, this hack has some large tradeoffs associated with it, because initialization is a load bearing part of gopls: it breaks features like "Rename symbol" and "Find all references", and it occasionally causes the wrong imports to be pulled in. However, buggy as it is, this hack in essence describes what we think the desirable IWL behavior would be:go list
and lazy loads package data into the currently "active" snapshotWhat did you expect to see?
This issue is a feature request.
We would appreciate any tips/guidance in writing an upstream-able patch, or a better hack.
Editor and settings
No response
Logs
No response
The text was updated successfully, but these errors were encountered: