Vim-go: guru definition is much slower than godef

[LK4D4]

Actual behavior

go to definition is very slow even for moderate sized projects, I think it's like hundreds times slower. godef was milliseconds, guru is 5-6 seconds for me in docker project

Expected behavior

go to definition is very fast

Steps to reproduce:

1. Update vim-go to latest
2. Try :GoDef in big projects
   

   Configuration

• vim version: neovim-0.1.3
• vim-go version 4f67ae2dc7281c6563b4e70ab2662f1a66eb2771
• go version go1.6.1 linux/amd64

[LK4D4]

Here is some numbers:

docker % time guru definition daemon/daemon.go:#44149
/home/moroz/project/workspace/src/github.com/docker/docker/vendor/src/github.com/docker/engine-api/types/container/hostconfig_unix.go:51:22: defined here as func (github.com/docker/engine-api/types/container.NetworkMode).IsContainer() bool
guru definition daemon/daemon.go:#44149  25.82s user 2.20s system 363% cpu 7.701 total
docker % time godef -f daemon/daemon.go -o 44149
/home/moroz/project/workspace/src/github.com/docker/docker/vendor/src/github.com/docker/engine-api/types/container/hostconfig_unix.go:51:22
godef -f daemon/daemon.go -o 44149  0.04s user 0.01s system 99% cpu 0.045 total

It's not like I think it's vim-go bug, but I propose to move back to godef as default for now :)

[fsouza]

Indeed I find guru to be very _slow_. Can we move to godef, please? :-D

[fatih]

It's slow and I agree. But guru definition will be faster with time (hopefully). It's much more reliable and fixes a lot of our past bugs (see CHANGELOG.md).

I'm not thinking to revert it and I believe this is the right way to go. Go's compilation also was slow, but they improved it with time. The point here is that it's always an equilibrium and we have to choose what to sacrifice. We earn stability, but lose some of the speed. The speed difference is 1-2 seconds (depending on the project). And I think it's ok, stability means it'll work always. The speed will be improved. I think you should open a bug on guru's repo, that would be a good start. Thanks!

[fsouza]

@fatih my main reason to switch back to godef was that vim-go + guru definition didn't behave well on new tabs. My current setting is: if the identifier is defined in the same file, jump to it in the same window, otherwise open a new tab. I failed to reproduce this configuration with vim-go. My configuration was:

let g:go_def_mapping_enabled = 0
autocmd FileType go nmap gd <Plug>(go-def-tab)
let g:go_def_use_buffer = 1

Did I use the wrong settings? x)

[fatih]

@fsouza you need to create a custom function to emulate the behaviour you want. The settings above are all valid (though go_def_use_buffer will be renamed to go_def_reuse_buffer). We don't check if the next target is the same file or not. We only check if there is already an existing buffer and then switch to it if you use go_def_use_buffer = 1

[fsouza]

@fatih thanks!

[fatih]

This is for example a CL that makes guru definition faster: https://go-review.googlesource.com/#/c/22526/ just adding it to show that this was what I mean when I said it'll be improved with time.