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.

[zoumo]

godef + godoc work well for me since godef fixed vendor support in rogpeppe/godef#33

[ramya-rao-a]

The latest update of the Go extension (0.6.54) has the integration with the language server available via a setting go.useLanguageServer

The features powered by the language server are Hover, Definition, Find All References, Signature Help, Go to Symbol in File and Workspace.

Give that a try and let us know if you see improvements in the performance

[abarisain]

That sounds great!

[ramya-rao-a]

@bruceauyeung Have you seen any perf issues recently?

I am looking at what else can we do here to make the gogetdoc experience better.

[ramya-rao-a]

Closing this issue as we haven't heard back from the OP in a while.

If anyone sees any perf issue when using gogetdoc, feel free to comment here and we can take a look at it.

[treed]

I definitely have issues with using gogetdoc on source that uses the Kubernetes client library. VSCode ends up spawning multiple gogetdocs that each take 1GB+ of RAM, consuming a lot of I/O and eventually causing my VM to swap.

Are the alternatives to gogetdoc feature-wise comparable?

[ramya-rao-a]

@treed You could go back to the default (just remove the setting that sets go.docsTool to gogetdoc
Or you can try out the language server (not available on Windows yet) by setting go.useLanguageServer to true

[ramya-rao-a]

Independently, I'll look into closing processes that were started but aren't needed anymore. #1265

[treed]

Okay, thanks. I'll try those out. I can't remember what prompted me to try gogetdoc instead of the default.

FWIW, all of the gogetdoc processes are for the same file (which is the one I'm editing) and seem to get launched in quick succession. I'm not sure if that matters for #1265, but it seemed worth mentioning.

[treed]

The default docs tool doesn't seem to actually give me documentation on hover. The language server does have reasonable-ish hover data, though. So far it hasn't taken my machine down, but I'm at the end of my workday. I'll report back tomorrow if I have any performance problems with it. Thanks!

[ramya-rao-a]

@treed @bruceauyeung @abarisain @leaxoy The latest update to the Go extension (0.6.69) has some perf improvements in place. Can you check if you still see slowness when using gogetdoc?

[abarisain]

Hi!

I unfortunately can't be of any help: I have been completly satisfied by the default configuration of the Go VSCode extension for quite a few releases, be it performance or completion wise.

[treed]

Sadly, I also can't really help. I got a new job in the meantime and no longer have access to the project that was causing the problem. But if anyone else can find a project using the Kubernetes client library, that's the one that drove this problem for me.