Linting and other on-save jobs much slower in July 2018 VSCode release

[StephenWeber]

I've been using VSCode on this project for a few months. VSCode and this plugin have been working fine right along, very few problems.

With the installation of the July 2018 release of VSCode, suddenly the linting features that run on file changes have gotten MUCH slower. Often the linting takes so long, that the changes I've made stack up and their results arrive several seconds later, and the advice for them sticks around for maybe one second. The linting is at least 5 seconds behind the changes that triggered it.

During linting VSCode uses a lot more processing power and my fans spin up; a few seconds after I stop making changes, CPU usage goes down and my fans stop.

Mac OSX 10.12.6 (16G1408)
MacBook Pro (15-inch, 2017)
Processor: 2.9 GHz Intel Core i7
Memory: 16GB

VSCode current version: Version 1.25.0 (1.25.0)
0f080e5267e829de46638128001aeb7ca2d6d50e
2018-07-05T12:56:27.472Z

vscode-go version: 0.6.84 - 29th June, 2018

Project/file details:
File length: 316 lines of test code
Project size: 58 go files, 11488 lines of go code

Related settings:

User Settings:
{
    "editor.scrollBeyondLastLine": false,
    "window.zoomLevel": 0,
    "files.autoSave": "afterDelay",
    "editor.rulers": [
        80,
        120
    ],
    "editor.minimap.enabled": false,
    "explorer.confirmDelete": false,
    "search.location": "sidebar",
    "editor.formatOnPaste": true,
    "editor.formatOnSave": true,
    "go.lintTool": "gometalinter",
    "editor.multiCursorModifier": "ctrlCmd"
}

workspace settings:
    "go.testFlags": ["--tags=unit", "-v", ],

I'd rather stick with gometalinter since that's what my team uses, but for testing I can try other linters. What else can I document to help figure this out?

[StephenWeber]

Managed to get a screenshot of my Activity Manager during one of the slowdowns. It shows varcheck and three megacheck processes running and requiring a lot of CPU.

https://www.dropbox.com/s/uqpqm4pmznpm284/Screenshot%202018-07-06%2012.26.30.png?dl=0

[uudashr]

Does using gometalinter directly from the shell give the same result?
FYI similar to gometalinter, https://github.com/golangci/golangci-lint but faster. Might less on CPU also.

[StephenWeber]

gometalinter from the shell does show up as one entry in my process list. It takes about 6 seconds to execute. My save settings were set to every 1000ms, so I think what is happening is: as I was changing my files, it would trigger another save and another run of gometalinter. Several runs were getting stacked up, until the CPU usage on gometalinter was slowing down the VSCode UI.

I'm just interested in what VSCode can do to protect itself from that situation. Other features, like formatting, have a timeout for that tool. That has its own problems, as I've seen in the help for why VSC isn't formatting documents. Alternatively, VSCode could kill processes it started that have had their files changed since it ran - that doesn't sound like a simple feature but would at least keep the processes from stacking up.

I suspect that golangci-lint would indeed be faster and a faster tool would trigger this less often.

[JacksonKearl]

Can you check if disabling the outline view makes a difference?

[StephenWeber]

I have outline view disabled by default, and was off for the above assessment. I can turn it on and see if it's same / worse?

…

On Mon, Jul 16, 2018 at 11:34 AM Jackson Kearl ***@***.***> wrote: Can you check if disabling the outline view makes a difference? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1775 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJYIMxbJEulahcUxCeJTsaNdwrt3e0nks5uHNzAgaJpZM4VFpnc> .

[ramya-rao-a]

Alternatively, VSCode could kill processes it started that have had their files changed since it ran - that doesn't sound like a simple feature but would at least keep the processes from stacking up.

We do have the above in place, but turns out there was a bug in it.
#1791 fixes it. Can you help us with testing this and let us know if this helps your case?

• Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
• Run code --install-extension Go-latest.vsix
• If the above fails with Error: end of central directory record signature not found, then clone this repo and use the Go-latest.vsix file from the cloned repo
• Reload VS Code

[StephenWeber]

This does appear to resolve this issue:
Testing method: turn on save-on-interval, every 100ms. Start typing crazy pathological formatting sequences (lots of brackets and parens, breaking lines in code, removing member accessors but leaving the .)
I also tried it with gometalinter and golangci-lint.

I could not reproduce the same behavior at all. golangci-lint was nearly imperceptible, gometalinter would use a good portion of CPU but the UI never froze and I never felt the system was overloaded.

Thanks for listening and glad it resulted in a fix!

[ramya-rao-a]

Thats great to hear @StephenWeber!
All credit goes to @JacksonKearl :)

Will ship in an update which will have this fix in the next few days.

[ramya-rao-a]

This fix is now out in the latest update (0.6.85) to the Go extension.