Vim-go: gopls is very slow in k8s.io/kubernetes

Created on 27 Apr 2019  路  14Comments  路  Source: fatih/vim-go

What did you do? (required. The issue will be closed when not provided.)

After the go modules update in Kubernetes, I've been noticing that :GoDef has been really slow. I assumed it was because guru/godef was searching the module cache instead of vendor. I tried setting GOFLAGS=-mod=vendor but that didn't help all that much. After trying to improve guru/godef I figured I'd try gopls with the new 1.20 release (before that I was on v1.16).

After upgrading, gopls was even slower and consumed a lot of CPU on my machine. I saw the gopls proces running on my machine but vim was not jumping to the definition. If I wait about 3 - 5 mins it will sometimes go to the right place.

I'm assuming that my environment is misconfigured but figured I'd open an issue to make sure I'm not missing anything.

What did you expect to happen?

:GoDef to be faster with the gopls update.

What happened instead?

:GoDef was much slower after using gopls.

Configuration (MUST fill this out):

  • vim-go version:
    v1.20

  • vimrc you used to reproduce (use a minimal vimrc with other plugins disabled; do not link to a 2,000 line vimrc):

let g:go_highlight_functions = 1
let g:go_highlight_function_calls = 1
let g:go_highlight_function_parameters = 1
let g:go_highlight_types = 1
let g:go_highlight_operators = 1
let g:go_highlight_build_constraints = 1



let g:go_def_mode='gopls'
let g:go_info_mode='gopls'
let g:go_disable_autoinstall = 0

let g:auto_save = 0
let g:auto_save_in_insert_mode = 0
  • Vim version (first three lines from :version):
VIM - Vi IMproved 8.1 (2018 May 18, compiled Feb 19 2019 12:07:46)
macOS version
Included patches: 1-950     

I use macvim, not sure if that changes anything.

  • Go version (go version):
$ go version
go version go1.12.1 darwin/amd64
  • Go environment (go env):
$ go env
GOARCH="amd64"
GOBIN="/Users/akim/go/bin"
GOCACHE="/Users/akim/Library/Caches/go-build"
GOEXE=""
GOFLAGS="-mod=vendor"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/akim/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.1/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/hh/0m51lb0n0tqbhkyr6rq6ny180000gp/T/go-build004257707=/tmp/go-build -gno-record-gcc-switches -fno-common"

Most helpful comment

Have you tried removing your $GOPATH/pkg directory and also cleaning your module cache (go clean -modcache)?

This did it for me. Thanks Billie!

All 14 comments

I've been able to use gopls successfully in kubernetes without such a long delay, but it does take gopls a while to initialize, so the first operation can be slow. After that it should be much faster.

But perhaps you're working in a different kubernetes package than I've tested in. Can you give more detail about what definition you're trying to jump to and from where?

Also, gopls is moving pretty fast. Have you updated it recently (:GoUpdateBinaries gopls)?

Thanks for getting back to me Billie!

I've been able to use gopls successfully in kubernetes without such a long delay, but it does take gopls a while to initialize, so the first operation can be slow. After that it should be much faster.

What's the usual expected time for this? I updated to the latest gopls binary and :GoDef still does not work. The gopls process has been running on my machine for the last 3 hours though, is that how long it usually takes to initialize?

A simple example that doesn't work for me is running :GoDef on app.NewControllerManagerCommand in the kube-controller-manager. But generally I can't get :GoDef in the repository to work. Does gopls still work for you after you pulled in the latest go modules changes in the Kubernetes repo or are you using :GoDef from Kubernetes vendored in another repository?

Hey, Andrew!

I tested this after my first response using latest kubernetes. It took a couple of minutes for gopls to initialize, but after that it was snappy.

A couple of things to be aware of: gopls expects your working directory to be within the module you're working in while in module mode.

You can get some useful logs with :let g:go_debug=['gopls'] and then using :echo g:go_lsp_log. It could be quite extensive, but may help us understand what's happening on your system.

Have you tried gopls with any non-k8s repos?

A couple of things to be aware of: gopls expects your working directory to be within the module you're working in while in module mode.

Yup, this was the case.

Have you tried gopls with any non-k8s repos?

Yes, it works with other repos. I can GoDef to kubernetes from another repo as a vendored dep as well. I'll try enabling logs like you mentioned and get back to you. Thanks!

You can get some useful logs with :let g:go_debug=['gopls']

Did you mean :let g:go_debug=['lsp']? :let g:go_debug=['gopls'] wasn't working so wanted to double check :)

Yes. Sorry about that.

I think I'm able to duplicate what you're seeing in module mode. But in GOPATH mode it works fine: initialization takes about 30-40 seconds.

I was able to get module mode to work by running go list before starting up Vim. I'll clear my cache and see if I can recreate the problem in module mode again, though, in case there's something that needs to change in vim-go or a bug needs to be created for gopls.

After clearing my cache, I can't duplicate the failures I thought I'd seen. I'll wait for your output from :echo g:go_lsp_log before continuing.

Thanks, Andrew! It looks like you tried jumping to the definition really quickly after opening the first Go file. I'd expect that first jump to take about 30-40 seconds (because it has to wait on gopls to initialize). How long did wait for it to complete?

Also, for us to get an idea of what's a reasonable time for gopls to initialize, can you try running time gopls query definition /Users/akim/go/src/k8s.io/kubernetes/cmd/kube-controller-manager /controller-manager.go:#1138? (you might need to adjust #1138 - it's the byte offset to evaluate in the source file. You can use g ctrl+g in vim to get the byte offset of the cursor).

On my system it took about 83 seconds, but don't worry, that only corresponds to the first time gopls has to load everything. gopls query definition has to initialize every time - vim-go will be _much_ faster after that first one.

I ran it for about 30 minutes and it never returned so I killed the process. I ran it on byte offset 1193 which should GoDef to NewControllerManagerCommand.

$ time gopls query definition /Users/akim/go/src/k8s.io/kubernetes/cmd/kube-controller-manager/controller-manager.go:#1193
^C
real    28m4.396s
user    28m3.322s
sys 0m5.765s

I ran it with -logfile as well but there were no logs either (in fact, the log file wasn't even created either).

The good news is that the problem doesn't seem to be vim-go, then. The bad news is that I'm not quite sure what's wrong. Have you tried removing your $GOPATH/pkg directory and also cleaning your module cache (go clean -modcache)? If you do either of those, it's probably a good idea to run GO111MODULE=on go list in /Users/akim/go/src/k8s.io/kubernetes before trying the gopls query definition again.

I'd recommend updating to the latest gopls before doing any of that (:GoUpdateBinaries gopls in vim-go should make that pretty easy).

If none of that works, it's probably time to create an issue for gopls in github.com/golang/go.

Thanks Billie, let me try that and get back to you!

Have you tried removing your $GOPATH/pkg directory and also cleaning your module cache (go clean -modcache)?

This did it for me. Thanks Billie!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

danielmanesku picture danielmanesku  路  4Comments

andrejvanderzee picture andrejvanderzee  路  3Comments

orlangure picture orlangure  路  3Comments

cassiobotaro picture cassiobotaro  路  3Comments

mnarrell picture mnarrell  路  3Comments