Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: startup is slow even with shared cache #48844

Closed
mattdee123 opened this issue Oct 7, 2021 · 5 comments
Closed

x/tools/gopls: startup is slow even with shared cache #48844

mattdee123 opened this issue Oct 7, 2021 · 5 comments
Labels
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

@mattdee123
Copy link

What did you do?

I use vim-go, and I generally open and close many vim windows throughout the course of the day. Working on a large codebase, I have noticed that each time I open a new vim, the gopls client takes a while to be responsive. I am using the shared daemon, so I expected each subsequent client to start up quickly.

To reproduce:

  1. Obtain a large codebase. I used this script to generate one for testing with 2047 packages.
  2. Add the following configuration to .vimrc: let g:go_gopls_options = ['-debug=:0', '-remote=unix;/tmp/gopls-daemon-socket', '-logfile=auto', '-rpc.trace']
  3. Start gopls server with gopls -listen="unix;/tmp/gopls-daemon-socket" -logfile=auto -rpc.trace
  4. Open a file in vim, immediately try to jump to declaration. After hanging for over 10 seconds, it is eventually responsive.
  5. Repeat step 4. See the same delay.

What did you expect to see?

I expected step 5, and all subsequent vim instances to benefit from the shared cache.

I recognize that my expectations may have been off, but this was something I was hopeful a shared daemon would fix.

What did you see instead?

The second instance was just as slow to start up as the first. Below are the logs generated
client1.log
client2.log
daemon.log
Additionally, the debug server confirmed that both clients were using the same cache
Screen Shot 2021-10-06 at 2 34 08 PM

Build info

golang.org/x/tools/gopls v0.7.2
    golang.org/x/tools/gopls@v0.7.2 h1:kRKKdvA8GOzra8rhSFDClOR7hV/x8v0J0Vm4C/gWq8s=
    github.com/BurntSushi/toml@v0.4.1 h1:GaI7EiDXDRfa8VshkTj7Fym7ha+y8/XxIgD2okUIjLw=
    github.com/google/go-cmp@v0.5.6 h1:BKbKCqvP6I+rmFHt06ZmyQtvB8xAkWdhFyr0ZUNZcxQ=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.4.2 h1:Gz96sIWK3OalVv/I/qNygP42zyoKp3xptRVCWRFEBvo=
    golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
    golang.org/x/sys@v0.0.0-20210809222454-d867a43fc93e h1:WUoyKPm6nCo1BnNUvPGnFG3T5DUVem42yDJZZ4CNxMA=
    golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c h1:C0nyHiBU2m0cR6hDiUORWqQIt3h37wsp1255QBSSXqY=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.2.0 h1:ws8AfbgTX3oIczLPNPCu5166oBg9ST2vNs0rcht+mDE=
    mvdan.cc/gofumpt@v0.1.1 h1:bi/1aS/5W00E2ny5q65w9SnKpWEF/UIOqDYBILpo9rA=
    mvdan.cc/xurls/v2@v2.3.0 h1:59Olnbt67UKpxF1EwVBopJvkSUBmgtb468E4GVWIZ1I=
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Oct 7, 2021
@gopherbot gopherbot added this to the Unreleased milestone Oct 7, 2021
@hyangah hyangah modified the milestones: Unreleased, gopls/on-deck Oct 7, 2021
@hyangah hyangah added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 7, 2021
@findleyr findleyr added the gopls/performance Issues related to gopls performance (CPU, memory, etc). label Oct 8, 2021
@stamblerre stamblerre changed the title x/tools/gopls: Startup is slow even with shared cache x/tools/gopls: startup is slow even with shared cache Oct 14, 2021
@stamblerre stamblerre self-assigned this Oct 15, 2021
@stamblerre
Copy link
Contributor

The duplication of the workspace folders in the session seems like a bug on our end, so we'll investigate.

@stamblerre stamblerre removed their assignment Oct 19, 2021
@gopherbot
Copy link

Change https://golang.org/cl/356933 mentions this issue: internal/lsp: don't add multiple views for the same folder

gopherbot pushed a commit to golang/tools that referenced this issue Oct 19, 2021
When we add a view, we should check if we already have a view for the
given folder.

Updates golang/go#48844

Change-Id: I0de27d420e2b4df3b33b913ae27b108bab6b7d12
Reviewed-on: https://go-review.googlesource.com/c/tools/+/356933
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
@findleyr
Copy link
Contributor

This is likely due to go list performance on that number of packages. Moving to the next milestone for confirmation.

@findleyr
Copy link
Contributor

findleyr commented Apr 5, 2022

A while ago I added the "experimentalCacheKey" option, which allows re-using a lot of type-checked packages. That would probably help here, but it needs investigating.

If it helps, I believe we can enable this behavior by default.

@findleyr findleyr removed this from the gopls/v0.8.4 milestone Apr 5, 2022
@findleyr findleyr added this to the gopls/on-deck milestone Apr 5, 2022
@findleyr findleyr modified the milestones: gopls/later, gopls/v0.12.0 Apr 25, 2023
@findleyr
Copy link
Contributor

gopls@v0.12.0-pre.1 uses a shared cache to persist derived package information across restarts. As a result, startup time for Kubernetes on my computer was reduced from 25s->7s (or 3s using recent go list optimizations not yet released).

I am going to close this as tentatively resolved. Please comment if you try out the prerelease and do not observe an improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

No branches or pull requests

5 participants