all tools should be run in a dedicated CPU scheduling group to keep UI smooth

[redbaron]

Currently on a big enough project, running gometalinter causes detrimental impact on UI responsiveness.

At least on a Linux system, it can be solved by placing CPU intensive processes in their own scheduling groups. There are few ways to do it, but easiest would be to make use of autogroup feature (http://man7.org/linux/man-pages/man7/sched.7.html) where session leaders are placed into their own CPU scheduling group.

In nodejs spawned process can be made session leader, by passing detached option to child_process call (https://nodejs.org/api/child_process.html#child_process_options_detached), adding that flag to runTool would achieve desired result.

Possitive effect can be demonstrated if running gometalinter in a terminal, while continue to navigate files in VSCode UI, despite quite heavy load VSCode remains responsive, that is because shell in a terminal is a session leader and places all its processes into a separate CPU scheduling group. CPU time is then distributed among groups first according to their weight and only then between processes withing group.

[mattetti]

@redbaron it sounds great, are you working on a PR for this or waiting for some kind of approval from @ramya-rao-a ?

[redbaron]

neither :) proposed idea for somebody to implement. If I remember correctly it wasn't only about adding the flag, it also requires using child_process.spawn (which supports flag) instead of child_process.execFile (which doesn't) and there was some semantic difference between them.

[stamblerre]

gometalinter is now deprecated (https://github.com/alecthomas/gometalinter), and it sounds like this issue is specific to it. @redbaron: is this still an issue for you?

[redbaron]

@stamblerre , issue wasn't specific to go metalinter. Any CPU intensive task spawned as a subprocess will compete with vscode for CPU cycles, unless placed in a separate scheduling group

[stamblerre]

Added a comment to golang/vscode-go#104 (comment). I'll close this issue in favor of golang/vscode-go#104 as this repo is migrating: #3247.