code completion really slow on Windows

[mattetti]

OS: Windows 10
16GB ram, i5 CPU

I'm switching back and forth between mac and windows to develop the project I'm working on and I noticed that the code completion on Windows is much much slower than on Mac.
Hovering a type is fast as expected, but the code completion (automatic or via control + space takes a few seconds making it unusable.

I'm not sure what's going on, nor what part of the code would be slower on windows than mac but I'm willing to look into it if I can get input from people who would have a clue. @lukehoban @ramya-rao-a or anyone, any pointers on where to start?

[ramya-rao-a]

We use gocode for autocomplete in the Go extension.
You can try running the autocomplete command from gocode in the command line and compare performance in the 2 platforms

[mattetti]

That's a good idea, let me benchmark both platforms using the same version of Go and gocode and against the same codebase and let see of this is where the bottleneck is.

…

On Mon, Dec 26, 2016, 07:35 Ramya Rao ***@***.***> wrote: We use gocode <https://github.com/nsf/gocode> for autocomplete in the Go extension. You can try running the autocomplete command from gocode in the command line and compare performance in the 2 platforms — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#696 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAcQAbZC926sRfqQmdCh49PyVgy9blks5rL97AgaJpZM4LUgVK> .

[mattetti]

@ramya-rao-a so I'm back on Windows and I looked at the underlying issue. As you suspected gocode is being extremely slow. I killed the daemon started by vscode and started one manually in debug mode. What I see is that gocode rebuilds all packages every time it receives a request. That seems to be related to the go build issue I brought up earlier requiring a -i. I'll investigate more, @nsf might know more, I also reporting my findings in this issue nsf/gocode#378

[mattetti]

As per the discussion in the gocode issue, the problem is that this extension uses an experimental feature that seems buggy on Windows. By default VSCode-Go turns on gocode autobuild which rebuilds all packages every single time making it unusable.

Is there a way to have a different default value for windows vs mac/linux? VSCode being a Microsoft product, I expect that Windows support is quite important :)

[ramya-rao-a]

By default VSCode-Go turns on gocode autobuild which rebuilds all packages every single time making it unusable.

You can set "go.gocodeAutoBuild": false in the settings, and the experimental feature will not be used.

There is a note on this in the README, I had forgotten about it :(

As of now there is no way to provide different default values for a configuration setting based on platform.
So I guess, this will have to stay as is.

[mattetti]

@ramya-rao-a what's the logic for having that on by default? The setting is quite hidden and the experience on Windows is really really bad unless turned off. I'm going to investigate how to make gocode's autobuild work properly on Windows but I would strongly suggest to consider turning off this option until it's fixed. Otherwise you are going to alienate Windows users.

[ramya-rao-a]

what's the logic for having that on by default

Say you make a change to a package, but don't go install it. The change will not be visible to gocode without this setting. Therefore, to keep auto-complete results as "fresh" as possible, this setting was enabled by default.

I have a Windows machine and I haven't noticed any slowness in auto-complete. Though, it might depend on how large and complex the code base is.

Your suggestion in the other thread of building with -i might help here.
I'll look into that more, and if that pans out, then we can remove the usage of auto build altogether.
Or may be use go build -i in gocode itself when autobuild is set.

[mattetti]

That's interesting, could you do me a favor and when running VSCode with autobuild on, try killing gocode and start it from the cmd prompt using gocode.exe -debug -s -sock tcp -addr 127.0.0.1:37373
and then try to trigger the autocompletion. I wonder if it rebuilds packages for you too or not.

I'm on Windows 10 btw. My colleague sees the same issue and we have a few cgo packages. But I just noticed we are on Go 1.8 so it might be related.

[mattetti]

After further investigation... I have no idea what was wrong. I removed the executable, added some debug statements, rebuilt it and copied it (for some reason go install wasn't moving the file properly). After that, autobuild worked as expected on Windows 10, VSCode, autobuild on, Go 1.8.
I can only assume something was wrong with my system and my coworkers.

It might have been something weird with an old version of gocode running and the new one not installing properly or something else. Anyway, I can't repro on my machine anymore so I will close this story.

[ramya-rao-a]

Well, we have a happy ending then :)
Thanks for taking the effort to investigate @mattetti

[kumarharsh]

This happens for me too, especially since including some cgo packages such as github.com/lestrrat/go-libxml2, which won't compile on my windows setup (and I can't seem to find all the pieces to get libxml2 working under windows). I build and run the golang app via a linux docker container, so the code runs fine, but vscode, being under windows, keeps throwing errors about undefined references due to gocode trying to build the project under Windows. And apparently, this takes a lot longer than if the error hadn't been there.

I've suffered so long with this issue, when all I had to do was set autobuild:false 😆

[nsf]

Autobuild feature is a hack, the proper way to do it for a program like gocode is to parse source files directly instead of relying on up-to-date and built package files. I don't have time or enough enthusiasm to be honest for such a big refactoring, so it won't happen any time soon within gocode project. Maybe somebody will make a better gocode alternative. I've seen some attempts, sadly they don't process the source files, but follow the same path and use binaries. Which doesn't make them much different from what gocode can offer. For a proper autocompletion tool it's important to parse source files for up-to-date results and for documentation also. Maybe one day somebody will make something like that. Go is a simple language to process and analyze. But seems like in open source communities if there is a tool which does the job at least to some reasonable level of acceptable, nobody wants to make a better one. And I'm not judging, people do whatever and whenever they feel like doing. So am I. But yeah, sorry about that little chaos caused by autobuild.

[kumarharsh]

But seems like in open source communities if there is a tool which does the job at least to some reasonable level of acceptable, nobody wants to make a better one.

Right on point. @nsf - maybe you can add this to the gocode README - might act like throwing the gauntlet for a better tool.
From my experience, go works atleast 2-3x faster on unix machines w.r.t Windows, which causes gocode and other go tools to just work on unix machines. Working with go on Windows is a lot more painful. Some of the issues I run into almost daily:

• autocomplete (gocode) is slow - which this issue is already about.
• 'Go to references' and related bins take more time on Windows.
• Package management with glide is sometimes a very painful exercise.
  ...

These are just observations, not really directed at anyone. I really appreciate the work which has been done to make golang a great language to work with. Personally, I lack time to contribute to golang tools as I don't have enough time to dive deep into the language. I hope someone does though 🙂 🙏

[ramya-rao-a]

For a proper autocompletion tool it's important to parse source files for up-to-date results and for documentation also

The best alternative I believe is to get the completion feature from a language server. We are working with Sourcegraph to use their Go language server in the VS Code Go extension. It is still very early in the works but will be the right solution down the road.