vscode triggeres too many go build/lint/... tasks

[grobie]

First of all, thanks for all your work on vscode and the go plugin, the integration is awesome.

My issue is that vscode can easily render my system unusable for minutes by triggering many parallel tasks for the same actions:

• Using gorename and changing many files at once, then selecting Save All seems to start multiple build / compile jobs, supposedly one for each changed file? I had to restart my laptop as no user input was possible anymore.
• Using go-metalinter on save seems to run the linters across the whole project even if only a single file has been changed. Multiple files saves in short succession will consume all CPU for minutes on a bigger project (kubernetes, prometheus).

I disabled metalinter already for that reason, here is my user config:

// Place your settings in this file to overwrite the default settings
{
    "files.trimTrailingWhitespace": true,
    "files.insertFinalNewline": true,
    "go.gopath": "/home/grobie/code/go",
    "go.formatTool": "goreturns",
    // "go.lintTool": "gometalinter",
    // "go.lintFlags": ["--disable-all", "--deadline=1m", "--enable=gofmt", "--enable=golint", "--enable=vet", "--enable=staticcheck", "--enable=unconvert", "--enable=unused"],
    "window.zoomLevel": 0,
    // "editor.wordWrap": false,
    "workbench.statusBar.visible": true,
    "workbench.activityBar.visible": true,
    "workbench.iconTheme": "vs-minimal",
    "workbench.welcome.enabled": false,
    "workbench.colorTheme": "Visual Studio Dark"
}

Here is an example of all the builds started after a gorename and save all in 20+ files

Is there anything I can do to limit the lintTool to the currently changed file (package)? Are there any other options I missed to improve the behavior?

[ramya-rao-a]

There is nothing I know of that you (as a user) can do at the moment to reduce the triggering of build/lint/vet on multiple files when Save All is used.

We should see if there is a way to identify a Save All event vs Save event in which case the extension can be smarter and trigger build/lint/vet on a package only once even if multiple files in the package was saved.

[grobie]

Thanks @ramya-rao-a! Should I create another issue to run go-metalinter only on the changed file/package instead of the whole repository? Saving a file a few times in succession can cause a similar amount of running processes and a similar situation of a stalled system.

[ramya-rao-a]

gometalinter cannot run on a file as far as i know. It needs to run on a directory/package.

We don't run it on the whole repo, we run it on the parent directory of the file that was saved.

If linting does get expensive, then a better solution would be to not run lint on save, but rather run it after a delay.

[roylee17]

Is there a way to TOGGLE the linter, or manually run the linter in vs code?

Currently, I have to manually modify the configs to achieve this.

Thanks

[ramya-rao-a]

@roylee17 Do you mean the settings when you say configs?

[roylee17]

@ramya-rao-a Yes, is there an command that I can run manually, and/or create a keybinding for that command?

[ramya-rao-a]

@roylee17 Not at the moment, but I am sure there is an issue tracking that as well. I'll try and find it and link it here

[apiarian]

In the meantime I've set up this couple of tasks:

{
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "megacheck",
            "type": "shell",
            "command": "megacheck ./...",
            "group": "test",
            "presentation": {
                "echo": false,
                "reveal": "silent",
                "focus": false,
                "panel": "shared"
            },
            "problemMatcher": "$go"
        },
        {
            "taskName": "lint",
            "type": "shell",
            "command": "go vet -composites=false ./...",
            "group": "test",
            "presentation": {
                "echo": false,
                "reveal": "silent",
                "focus": false,
                "panel": "shared"
            },
            "problemMatcher": "$go"
        }
    ]
}

(note, I'm disabling composites on vet because that's noisy and I like my un-labeled struct literals)

[atombender]

@ramya-rao-a I noticed that if you enable Gometalinter, go tool vet is still run on save. But Gometalinter's default set of linters include vet, so unless one has messed with the linter args, this is redundant. I suggest that vet is automatically disabled if you're using Gometalinter.

[ramya-rao-a]

@roylee17 In the latest update to the Go extension (0.6.69), you can manually run the linter on your code using the commands Go: Lint Current Package and Go: Lint Workspace. You can use these commands and disable the lint on save feature if you want.

@atombender That would require me to also check if default set of linters havent been tinkered with using the go.lintFlags. Instead I would leave it up to the user to disable vet on save feature when using gometalinter

[atombender]

@ramya-rao-a While true, it's also probably true that a lot of people have both enabled without realizing it. I think it's worth re-evaluating the whole thing, to be honest.

I'm not sure I understand why there's a go.vetOnSave when go.lintOnSave exists. Surely go tool vet is just another a linter, and if you want linteing, you want to choose a single one. Having both vet and Gometalinter introduces potential duplication and inefficiency. And the Go extension is already chock full of tools that are run that slow everything down.

[ramya-rao-a]

Good point, PRs are welcome.

[Southclaws]

I'm running into this quite a lot on large projects. One of the reasons I love working with this extension is the lint-on-save features so I don't want to disable that (it runs fast enough for me). The issue is if I change things in quick succession or do a Save All when changing lots of things.

Surely there's a way the extension knows the PID of the linter? If so, then I think the extension should kill the existing lint task before starting a new one. Meaning only one lint process is running regardless of how it was triggered. This would mean there's no need to figure out if Save or Save All was used and also speeds up the process when making little changes in quick succession.

My TypeScript is rusty but I could look into this in future. I'm not totally sure how the extension triggers linters and keeps track of them but keeping the PID stored and killing it sounds realtively simple.

If I get anywhere with this, I'll submit a PR. But it would be useful to have some feedback on this idea from people more familiar with the extension's codebase!

[ramya-rao-a]

@Southclaws At the moment, we cancel the current running linter process before starting a new one, but we dont wait for the process to be killed, before starting a new one. You can see this in https://github.com/Microsoft/vscode-go/blob/0.6.84/src/goLint.ts#L45 and https://github.com/Microsoft/vscode-go/blob/0.6.84/src/util.ts#L585

You can find instructions to run the extension from source at https://github.com/Microsoft/vscode-go/wiki/Building,-Debugging-and-Sideloading-the-extension-in-Visual-Studio-Code#building-and-debugging-the-extension

If you can figure out why the current process of killing existing processes doesnt help you, then that would be helpful.

[stamblerre]

Since this issue has not had any activity for over a year, I will close it in favor of a new umbrella issue for improving VS Code Go's handling of subprocesses: #3044. It will be easier to track improvements with one issue, instead of many hard-to-find ones.

As an alternative, you can use the language server, which handles cancellation.

[stamblerre]

Duplicate of #3044