hover info / goto definition is very slow when using gogetdoc

[bruceauyeung]

when i hover on a struct field, hover info is very slow to pop up (most time 4 ~ 5 secs). in the top list,most time i can see 2 gogetdoc processes ( up to 4 ) are consuming lots of cpu time ( total over 300% , almost every logic cpu is over 80% ) . and even i hover the second time ( 3rd time ... ) onto the same struct field, it still is very slow.

when i move cursor onto a method ( only use keyboard without mouse click ) and then hit F12, go to definition is very slow too.

vscode-go:0.6.50
vscode:1.7.2
os:kubuntu 16.04 64bit
cpu:Embedded AMD Opteron(tm) Processor 23KS EE, 4 Core, 2000MHZ

[leaxoy]

It's right, may be we should find out what slow down it, or use godef+godoc back.
But godef is broken for some package, and it's seems that it's author has long time no maintain it.

[bruceauyeung]

@leaxoy after upgrading to vscode-go 0.6.51, the problem still exists.

[leaxoy]

I see, it's because gogetdoc, a bit slow than godef + godoc.

[leaxoy]

There are some proposals:

1. use guru, but a little complex to parse result (even with -json flag)
2. patch godef, make it works well with all packages
3. use a new backend language server sourcegraph-go (but it still wip)

[ramya-rao-a]

@leaxoy @abarisain @zmb3
Was this expected or is there anything we can do to improve the performance while using gogetdoc?
In my Windows 10 and Mac, I don't see any perf issues.

@bruceauyeung Thanks for reporting this. As a workaround, you can always switch back to using godoc by changing your settings.

We will eventually move to using a language server, but not any time soon...

[leaxoy]

Is sourcegraph-go ? That looks great, but it is still work in progress. Is it stable enough to use in production?

[zmb3]

Gogetdoc is a little slower than godef, but that's because it does more. I hardly notice a difference in my machine. 4-5 seconds sounds way too long. Typical calls to gogetdoc generally take hundreds of milliseconds in my experience. More info on the environment where it is slow would be helpful. Is it a very large project and/or gopath? Old machine? We can definitely look into optimizing gogetdoc further. For example garbage collection can be disabled since it's a short lived process. One thing that struck me is the report of 4-5 gogetdoc processes running at a time. I wouldn't expect more than 1.

…

On Wed, Nov 30, 2016 at 3:01 PM Ramya Rao ***@***.***> wrote: @leaxoy <https://github.com/leaxoy> @abarisain <https://github.com/abarisain> @zmb3 <https://github.com/zmb3> Was this expected or is there anything we can do to improve the performance while using gogetdoc? In my Windows 10 and Mac, I don't see any perf issues. @bruceauyeung <https://github.com/bruceauyeung> Thanks for reporting this. As a workaround, you can always switch back to using godoc by changing your settings. We will eventually move to using a language server, but not any time soon... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#667 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHLav2rYKTsDRte4T-mOMwR0clJY_yNlks5rDfI4gaJpZM4K_2fN> .

[abarisain]

I was certainly not expecting such delays. On my computer, I experienced delays up to 15s when doing go to implementation (jumping to stuff in go's stdlib).

I noticed that it was slower when developing my version of the plugin, and talked to zmb3 about this. He improved gogetdoc and I was down to delays more in the 500ms range.

My gopath is quite small, but I have a moderately sized vendor folder. I'm testing on Sierra with go 1.7.whateveristhelatestone.

I think some profiling is in order, as my cpu definitely goes nuts when looking up definitions. A nice way to kill the plugin functionality is to hold CMD (I often use cmd click instead of F12) and hover a couple of stuff without waiting. If I simply hover and wait, things are much better.

Talking about sourecgraph, isn't it only a cloud service ? It may not fit many use cases: for example, the code I edit comes from a private repo xith only vendored dependencies. I'd expect the plugin to only pick up the documentation for the vendored version of the library I'm using.

[bruceauyeung]

More info on the environment where it is slow would be helpful. Is it a very large project and/or gopath? Old machine?

@zmb3 yes, i think it is, it's kubernetes project. this project is about 483MB in code size after being tarred.
this machine is a blade server. old one.
more detailed info about cpu is here: http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=48059

all informations i can get about hard disk is here:

*-disk:2
description: SCSI Disk
product: Logical Volume
vendor: LSILOGIC
physical id: 1.0.0
bus info: scsi@8:1.0.0
logical name: /dev/sda
version: 3000
size: 136GiB (146GB)
capacity: 136GiB (146GB)
capabilities: 15000rpm partitioned partitioned:dos
configuration: ansiversion=2 logicalsectorsize=512 sectorsize=512 signature=0009283a

[bruceauyeung]

i find another problem.
after i opened a go source file (resthandler.go), i move curor ( using mouse ) in the left side blank area of edit window, not right side, not hovering onto any keywords, variables, methods, vscode-go will try to load something( the background gogetdoc process launched), after more than 4 secs it displays package's comments (package comments lays in another go source file named doc.go)

top info follows:

1851 root 20 0 428336 419532 3580 R 129.6 1.3 0:12.13 gogetdoc
11706 root 20 0 586116 578388 3580 R 129.3 1.8 0:16.67 gogetdoc
11717 root 20 0 478012 468992 3580 R 125.0 1.4 0:14.35 gogetdoc
12133 root 20 0 159336 151060 3580 S 115.5 0.5 0:04.02 gogetdoc
12112 root 20 0 154020 145676 3580 R 102.3 0.4 0:03.86 gogetdoc
12210 root 20 0 63368 56728 3580 R 43.8 0.2 0:01.33 gogetdoc

[zmb3]

Yeah that particular issue is just that Code is always trying to find something under your cursor to pass to gogetdoc. I wonder if we can modify the extension so that it only calls gogetdoc when there looks to be a valid identifier under the mouse.

…

On Wed, Nov 30, 2016 at 7:01 PM Bruce Auyeung ***@***.***> wrote: i find another problem. after i opened a go source file, i move curor ( using mouse ) in the left side blank area of edit window, not right side, not hovering onto any keywords, variables, methods, vscode-go will try to load something( the background gogetdoc process launched), after more than 4 secs it displays package's information 1851 root 20 0 428336 419532 3580 R 129.6 1.3 0:12.13 gogetdoc 11706 root 20 0 586116 578388 3580 R 129.3 1.8 0:16.67 gogetdoc 11717 root 20 0 478012 468992 3580 R 125.0 1.4 0:14.35 gogetdoc 12133 root 20 0 159336 151060 3580 S 115.5 0.5 0:04.02 gogetdoc 12112 root 20 0 154020 145676 3580 R 102.3 0.4 0:03.86 gogetdoc 12210 root 20 0 63368 56728 3580 R 43.8 0.2 0:01.33 gogetdoc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#667 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHLav84s726sBUx22BYO9D5vuPc3XTelks5rDiqKgaJpZM4K_2fN> .

[zmb3]

I ran gogetdoc on the resthandler.go file in the kubernetes project and queries were taking 1.1s, which is not instantaneous but really not bad given the size of the project.

Interestingly enough, running with GOMAXPROCS=1 (or even 2), the query time is down to .70s. There's not much work that can be done in parallel here, so we're probably just losing time due to scheduler overhead. As an added bonus, gogetdoc won't eat up as many CPUs with this setting.

@bruceauyeung could you please go get -u github.com/zmb3/gogetdoc and report your results with GOMAXPROCS=1?

[bruceauyeung]

@zmb3 after i go get -u github.com/zmb3/gogetdoc, i tested at least 2 times seperately between export GOMAXPROCS=8 and export GOMAXPROCS=1, and when export GOMAXPROCS=1, it takes more time ( over 8 secs ) than when export GOMAXPROCS=8 ( about 3 secs, maybe a little less )

so i think, on my machine, export GOMAXPROCS=8 is better than export GOMAXPROCS=1.
compared to enabling-gc, disabling-gc makes gogetdoc at least 1 sec faster with my feeling.

by the way, the machine has 8 logic CPUs.

[zmb3]

Hmm, so the GOMAXPROCS isn't a one-size fits all solution. Bummer.

One thing that would help would be for the extension to make sure not to stack up processes, meaning if the user moves their cursor before the results come back then the process should be cancelled before starting a new one.

Additionally, if there are cases where the extension needs only a definition and not the doc, then godef should probably be preferred there.

While I plan to continue to work on performance, I'd like to point out that gogetdoc has been in use by vim-go and Atom for the better part of a year and we haven't received reports of performance issues. I'd be hesitant to do anything drastic in this extension to accommodate a single old machine. In the meantime, you can always enable the old "godef+go doc" behavior if that works better for you.