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:
- Obtain a large codebase. I used this script to generate one for testing with 2047 packages.
- Add the following configuration to
.vimrc: let g:go_gopls_options = ['-debug=:0', '-remote=unix;/tmp/gopls-daemon-socket', '-logfile=auto', '-rpc.trace']
- Start
gopls server with gopls -listen="unix;/tmp/gopls-daemon-socket" -logfile=auto -rpc.trace
- Open a file in vim, immediately try to jump to declaration. After hanging for over 10 seconds, it is eventually responsive.
- 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
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=
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
goplsclient takes a while to be responsive. I am using the shared daemon, so I expected each subsequent client to start up quickly.To reproduce:
.vimrc:let g:go_gopls_options = ['-debug=:0', '-remote=unix;/tmp/gopls-daemon-socket', '-logfile=auto', '-rpc.trace']goplsserver withgopls -listen="unix;/tmp/gopls-daemon-socket" -logfile=auto -rpc.traceWhat 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
Build info