High CPU usage resulting from frequent godef invocations via HoverProvider

[ironcladlou]

Any travel of the mouse over the editor region causes godef to be invoked almost continuously. Using top -a -o cpu -n 10 on OS X, Electron goes wild any time the mouse is moving. Watching the console with some debug logging in the GoHoverProvider revealed a surprising number of godef calls. It's very easy to get my current model 15" rMBP's jet engines roaring just by moving the cursor around for a few seconds.

The severity of this issue is seems pretty subjective. Apparently the way I use the trackpad while coding tends to make the current hover responsiveness and design problematic.

I like the hover feature and so am interested in how to make it more CPU efficient.

[ironcladlou]

A good workaround for me would be for hover to be disabled entirely unless I'm holding down a certain key (e.g. ⌘). I've been searching and can't yet find any way to accomplish it.

[ironcladlou]

I was experimenting with disabling GoHoverProvider, which on the surface achieves my goal of seeing hover info only when holding ⌘. However, while debugging usage of GoDefinitionProvider with GoHoverProvider I noticed something else: the use of the ⌘ key itself seems to amplify the excessive godef calls. For example, with the cursor resting still in the editor area, pressing ⌘ instantly invokes the GoDefinitionProvider, even when ⌘ is immediately used in a chord for some other command (e.g. copy, paste, opening the command palette, etc.).

This means calls to godef are happening when the user is pressing a very common key with no intention of obtaining contextual hover information.

I'm not yet seeing a way to configure the hover modifier key in VSCode.

[ironcladlou]

Looks like microsoft/vscode#3130 tracks the capability to change the peek definition modifier.

[lukehoban]

Thanks for the investigation on this @ironcladlou.

I haven't actually seen anything nearly as severe as you mention myself. I'm a bit surprised that you would seen Electron Helper CPU going up due to spawning godef - the latter should be a seperate process.

What may be a problem is the recent change to also invoke godoc as part of finding the definition (even though we don't yet actually display the docs during extrainfo). That does a somewhat CPU intensive scan of the resulting docs since godoc doesn't return results in a form that is easily processed for this need. We can definitely improve on this (and remove it from the extrinfo and gotodef codepath entirely for now if needed).

As for the number of godef processes spawned - I expect there will be a lot, but that hasn't itself been a noticeable performance issue. If it does turn out to be, I think the best approach would be to ensure we only have one godef process spawned at a time, and that we drop old queued requests when new requests come in.

As for removing the hover and cmd+hover behaviors by default - that's something VS Code can offer, but it shouldn't be the case that users feel they need to do that for performance reasons.

I'll leave this open to track improving the CPU performance of extrainfo and gotodefinition, since I believe that's the root cause here.

[ironcladlou]

I do see godoc processes spawning for each definition peek. I did verify that Electron Helper incurs the spike in CPU usage when processing the peek. Easy to reproduce by just hovering over a symbol and pressing ⌘ repeatedly. Not really a big issue in practice, unlike the HoverProvider which exhibits similar behavior but frequently due to typical mouse movement.

Disabling the HoverProvider was the big win for me personally. Although I do agree that the default hover behaviors should be able to remain on by default and any underlying performance issues resolved, I filed some upstream issues for configuration nonetheless because I'd like the ability to make any popup behavior totally modifier driven (as a means to eliminate distractions). The performance issues are separate.

[lukehoban]

A fix that should address the CPU issue is in 0.6.35. Let me know if you are still seeing issues.

[sgallagher]

I'm still seeing this issue on 0.6.35. Basically any time I type a . (dot/period) in VSCode, all of my CPUs (both physical and hyperthreading) go immediately to 100% usage, causing my system to slow to a crawl until it's complete.

This is VSCode 0.10.8 running on Fedora Workstation 24 against the following settings:

// Place your settings in this file to overwrite default and user settings.
{
    "go.buildOnSave": false,
    "go.lintOnSave": false,
    "go.vetOnSave": false,
    "go.formatOnSave": false,
    "go.gopath": "/home/sgallagh/go",
    "go.goroot": "/home/sgallagh/.gvm/gos/go1.5.3",
    "go.formatTool": "goreturns",
    "editor.insertSpaces": false
}

[lukehoban]

@sgallagher

That sounds like a different issue, since it's not related to hovering or godef.

Instead, it sounds like it's going to be an issue with https://github.com/nsf/gocode - possibly related to turning on autobuild. You may want to report an issue there, but would likely need additional details about your source code, what proceses are using 100% CPU, whether this happens once or repeatedly, etc.

[sgallagher]

@lukehoban Actually, it looks to be the same issue as #252 (I'm actually working on the same project, OpenShift Origin). I'll take this discussion to that ticket.

[sethgrid]

I just started having godef procs spawn and hammer the CPU on mac. 6 procs at 30% each, even after I closed vs code :(
vs code is the only thing that I would have that could invoke godef.

[sethgrid]

Fixed my issue with > Go: Install/Update tools

[ramya-rao-a]

Thanks for the update @sethgrid

[rajatdeshpande]

Hi Ramya,

Go: Install/Update tools is not fixing my issue on vscode version Version 1.19.2 (1.19.2) Mac.

go version go1.9.2 darwin/amd64

[ramya-rao-a]

@rajatdeshpande This issue is very old and the code behind the Go extension and VS Code has long since changed a lot. Please log a new issue with detailed description of the issue you are seeing