Slow autocomplete performance

[fvosberg]

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

I've created a small vimrc with vim-go,
opened a Go file "github.com/tarent/loginsrv/login/handler.go"
Jumped to line 38 (first line of func NewHandler)
Inserted config.
And hit for autocompletion.

What did you expect to happen?

The omnicompletion pop up to open fast.

What happened instead?

Waited several seconds (round about 7s) for the pop-up menu to show up. (Even after a second time, when I expected a sort of cache to be built)

Configuration (MUST fill this out):

• vim-go version: Current version installed with plug.

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

if empty(glob('~/.config/nvim-debug/autoload/plug.vim'))
	silent !curl -fLo ~/.config/nvim-debug/autoload/plug.vim --create-dirs
		\ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
	autocmd VimEnter * PlugInstall | source ~/.vimrc.test
endif

call plug#begin('~/.config/nvim-debug/plugged')
Plug 'fatih/vim-go', { 'do': ':GoInstallBinaries' }
call plug#end()

set nocompatible
set packpath=~/.config/nvim-debug,/usr/share/vim/vimfiles,/usr/share/vim/vim80,/usr/share/vim/vimfiles/after,~/.config/nvim-debug/after
packloadall!

syntax on
filetype plugin indent on
set number

• Vim version (first three lines from :version):

NVIM v0.3.2-24-gc8e7a44
Build type: Release
LuaJIT 2.0.5

• Go version (go version):

go version go1.11.2 darwin/amd64

• Go environment (go env):

GOBIN=""
GOCACHE="/Users/frederikvosberg/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/frederikvosberg/code/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.2/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/r1/tlbhy0rx3y76wtmr4k1l72qw0000gn/T/go-build847603310=/tmp/go-build -gno-record-gcc-switches -fno-common"

Which options do I have to speed this up? Did I miss some documentation?

Thanks in advance

[bhcleek]

In general, the first time autocompletion is invoked for identifiers from a package may be slow, but after that it should be faster.

There are some things you can do.

• update to the latest gocode with :GoUpdateBinaries gocode
• If you're installing your packages, then disabling gocode's -propose-source option by putting let g:go_gocode_propose_source=0 in your vimrc may help.

[fvosberg]

Thanks for the fast reply, I‘ll try that tomorrow in the morning.

One thing from my mind: Both invocations took the same amount of time. Seems like there is something wrong with my setup. Have you any idea, what could cause this?

Cheers
Fredi

[fvosberg]

I thought vim-go would use guru instead of gocode.

[bhcleek]

It can use either for getting info, but for autocompletions it uses gocode.

edit: fixed typo

[bhcleek]

#2050 may help; can you give it a try?

[bhcleek]

Kai Henry linked to a video that shows some of the gocode problems: https://s.natalian.org/2018-11-08/gocode.mp4

For anyone that's experiencing this problem, there's a few things to note.

First, vim-go now uses github.com/mdempsky/gocode instead of github.com/nsf/gocode. mdempsky's version does not autobuild packages for you, so source code has to be parsed, which results in longer request times. Whether vim-go tells gocode to parse source code can be configured with g:go_gocode_propose_source. ref: #1967

Second, the time it takes gocode to get the identifiers for a package the first time seems to be quite slow. But subsequent attempts at getting identifiers from that same package should be significantly faster.

Finally, it's important to know that if no autocompletions are attempted for some period of time (the last time I checked I think it was about 30 minutes), gocode's server component will exit and the next autocompletion attempt will start the server again and have to endure the longer wait times while gocode fills its cache again.

[powerman]

Disabling g:go_gocode_propose_source helps, but it's inconvenient. Autocomplete slowdown is very annoying, is there any way to make it work as fast as before? Maybe use some older version of gocode or vim-go?

[mnarrell]

You can drop to 1.18, this uses the NSF implementation which still works as expected. You can also disable g:go_gocode_propose_source, install your packages manually and bounce gocode. Im doing the latter, which seems tolerable at the moment.

[bhcleek]

The only option you have that's supported by vim-go is to install the packages that you want to autocomplete and then put let g:go_gocode_propose_source=0 in your vimrc.

github.com/nsf/gocode is not supported by vim-go; the author has very clearly said that he does not want to maintain it for the community. If you go that route, please do not file any issues about autocompletion problems here.

[powerman]

Just to make it clear if I understand correctly: with let g:go_gocode_propose_source=0 I need to run go install in each directory where I've modified any file just to see these modifications while autocomplete in file in some other directory, right?

How this is supposed to work? I've a project with dozens of packages, I've several files opened in vim (in different tabs), these files are usually from different packages… now I edit one file in one vim tab, like add new exported type, then switch to another tab to file in another package and try to autocomplete that new type… how and when I should run go install to make this work?

[bhcleek]

This is part of the problem with the new gocode: it doesn't autobuild packages, so if you add a new identifier and don't want are using g:go_gocode_propose_source=0, then you'll need to go install any package that has a new identifier that you want to be able to autocomplete before you attempt that autocompletion. There's also going to be some interplay with gocode's caching mechanism, but I'm not sure what the details of that are yet.

We're kind of stuck between reliability and performance. If you want better performance, then there are some manual steps that you need to perform to get reliable autocompletion results with the current state of github.com/mdempsky/gocode.

[powerman]

Maybe it is makes sense for vim-go to automatically run go install in background on file save (in case syntax check pass), except main package?

[bhcleek]

@powerman This has been discussed extensively before. See #2018 (comment).

If that's something you want to do, you can easily configure an autocmd in your vimrc to do it.

[mnarrell]

This is something similar to my approach. I don't install on save necessarily, but after each GoBuild, which is a leader mapping.

[fvosberg]

Thanks for your help, updating gocode didn't help, as expected, but disabling g:go_gocode_propose_source did it!

Ok, so this will be a workaround for now and I'll have a look at mdempsky/gocode#46, if I can help.

Thank you so much, I'll close this for now.

[BugRoger]

So, after reading through all issues regarding slow/non-working auto-complete our options today are:

1. Working auto-complete, but it takes 10s+ on a maxed out Macbook Pro i9 on a trivial project
2. Quick auto-complete but it doesn't work for vendored packages
3. Install everything in vendor. Anyone ever worked with Kubernetes?
4. Downgrade Go and use an unsupported Gocode

I think, I'm sticking with (1) and:

[korjavin]

How it has ended?
I still suffer.

[BugRoger]

vscode :D

[korjavin]

It's impossible to betray vim, but suffering from gocode is something bad.

[houglum]

Arrived at this thread years later - I'm still repeatedly waiting 10+ seconds for vim-go to load packages after starting vim. The solution I eventually arrived at was to not actually exit vim, but to close buffers within vim instead. In case it helps others, my current workflow to avoid the repeated initial load time is:

• cd to the root dir of my project, then open vim via vim
• Type :open ., which loads NERDTree for me
• Navigate in the tree to the Go file I want to edit, then hit enter to open that file
• Do my editing and deal with vim-go being slow to load the first time
• When done editing, I type :bd <space> <tab> to autocomplete and make sure I'm selecting the correct file/buffer to close, then hit enter to delete that buffer and close that window
• Suspend vim via <ctrl-z> and run whatever commands I need to
• When I need to edit another go file, I run fg to bring vim to the foreground, then start back at the :open . step again. But this time, vim-go doesn't need to do its initial package loading logic, so autocomplete just works quickly as intended.

[powerman]

@houglum Chances are your issue is different, so it's worth creating a new issue and provide more details including your vim config. Also, it's always a good idea to try disabling all other plugins and see is that helps - maybe it's because of some plugins conflict. And you may also want to killall gopls before running vim to ensure clean start. And don't forget to update vim-go and call :GoUpdateBinaries first.