Extension host processes on Mac eating CPU (typing lag in vscode)

[elsigh]

• VSCode Version: 1.4
• OS Version: OSX Mavericks 10.11.6

Steps to Reproduce:

1. Open my project
2. 

I tried uninstalling plugins but I don't know what to do that might be less of a time-suck. Maybe it's indexing for the go plugin or something, but it's making my editor unusable. And vscode without the go plugin is unusable for me too, so it's tricky.

[jrieken]

Can you run a ps -p <PID> to get more information about the process, esp its command line. That will allow us to figure out what process is going crazy... Any other insights about your workspace, like what files (go, JavaScript, TypeScript, etc)? Size? etc

[dwbruhn]

I have the same issue...it runs my fan constantly and burns through my battery. (No typing lag, though.)

• VSCode Version: 1.4.0
• OS Version: OS X El Capitan 10.11.6

10:25:09] $ ps -p 78859
  PID TTY           TIME CMD
78859 ??         3:30.61 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Stu

Note: "Code Helper" also continues to run even after I've quit VSCode.

My workspace is a Node.js module with most js files under 20KB. There are a few big-ish json files going up to 7 MB. The node_modules folder is pretty hefty, at ~300MB, mostly because of some CLDR dependencies.

Funny, I closed VSCode and reopened it, and now I have two Code Helper processes going crazy:

[jrieken]

@dwbruhn Thanks for the info. Can pipe the output of the ps -p command to a file? Unfortunately the important bits of the arguments are cropped in your sample...

[mh720]

Same issue here, VSC 1.4.0 osx 10.11.6, without VSC running, Code Helper is consuming 100% of a cpu:

$ ps -p 35565

35565 ?? 15486:08.03 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=extensionHost

Mine's been running over the last week and has racked up 257 hours of CPU time :)

[dwbruhn]

Here's mine:

  PID TTY           TIME CMD
21572 ??        10:36.69 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=extensionHost

I let it run for most of the day on Friday and the usage dropped down to a reasonable level, even while I was still working in VSCode. Just started making some edits today, though, and it's back up to ~100%.

[bpasero]

@elsigh @dwbruhn so does this reproduce even when you run without extensions loaded (using code --disable-extensions)?

[dwbruhn]

@bpasero Strangely, Code Helper isn't even near 100% today, even though I'm in the same workspace. If I can get it to reappear, I'll try the disable-extensions flag.

[marcevrard]

I experience the same issue with vscode 1.4 on OS X 10.11.6.
It does not reproduce when I disable all extensions.
Besides, I did several tests by disabling (moving the folder of) my installed extensions (in a binary search way) and it seemed the Excel Viewer extension was the one causing trouble.
Although, after uninstalling (using the uninstall command in vscode) several other extensions, the problem reappeared...

[dwbruhn]

@marcevrard Interesting, I actually don't have that particular extension. Here are mine:

Jul 25 15:49 DavidAnson.vscode-markdownlint-0.5.0/
Jun 17 13:07 DotJoshJohnson.xml-1.6.0/
Mar 28 19:24 ceps.theme-darcula-0.0.4/
Jul  6 13:59 dbaeumer.jshint-0.10.15/
Jul  6 13:59 dbaeumer.vscode-eslint-0.10.18/
Aug 16 14:42 donjayamanne.githistory-0.0.10/
May  9 16:02 gerane.Theme-Zenburn-0.0.3/
Aug 12 08:47 minhthai.vscode-todo-parser-1.7.0/
Jul 15 17:21 ms-vscode.Theme-MarkdownKit-0.1.1/
Jul 15 17:21 ms-vscode.Theme-TomorrowKit-0.1.3/
Aug  8 12:22 ms-vscode.js-atom-grammar-0.1.8/
Apr 25 11:23 nemesarial.dust-0.0.1/
Mar 28 19:23 smdl.theme-monoko-0.0.1/

Looks like the TODO parser and Git History extensions updated in the last few days...possibly one of those was the culprit and has been fixed by the author?

[marcevrard]

After removing HookyQR.beautify-0.1.8 the problem seems not to occur anymore.
@dwbruhn I also had the TODO parser and the Git History extensions installed. These versions seem fine indeed since the problem does not occur now on either. Let's see...
Here are my current installed extensions:

Shan.code-settings-sync-1.6.3/
alefragnani.Bookmarks-0.9.0/
alefragnani.project-manager-0.8.3/
christian-kohler.path-intellisense-1.0.2/
chrmarti.regex-0.0.6/
donjayamanne.githistory-0.0.10/
donjayamanne.python-0.3.21/
emilast.LogFileHighlighter-0.8.0/
formulahendry.code-runner-0.2.1/
minhthai.vscode-todo-parser-1.7.0/
mitchdenny.ecdc-0.10.3/
ms-vscode.cpptools-0.8.1/
seanmcbreen.Spell-0.8.6/
shardulm94.trailing-spaces-0.2.10/
spywhere.guides-0.5.0/
steve8708.Align-0.2.0/
yaruson.ascii-unicode-escape-0.1.0/

[dwbruhn]

Okay, the high CPU usage reappeared. I shut down all the processes, then restarted VSCode with --disable-extensions. So far, Code Helper is behaving...

[marcevrard]

@dwbruhn One of the extensions (from your list) I uninstall during the debug was the DavidAnson.vscode-markdownlint-0.5.0/. I've just tried to reinstall it but could not reproduce the high CPU Code Helper issue.

Actually, to reproduce the issue, I used to open the User settings and close the right column window to focus on the Default settings window. Each time the problem occurred, I could see the linting in the status bar showing 2 warnings. When it did not occur, no warning was shown. So my intuition is that this issue is correlated to the linting process.

[dwbruhn]

@marcevrard Thanks for the tip! Code Helper spiked again today, so I shut it all down, uninstalled the markdownlint extension, and restarted VSCode. Looking good so far...

[dwbruhn]

@marcevrard Scratch that, it's sitting around 100% again... :-(

[bkniffler]

I'm on Mac El Capitan.

I've removed all extensions. I've disabled git (git.enabled) and javascript validation (javascript.validate.enable). I've excluded node_modules folder via files.exclude. I still have the "Code Helper" hanging around eating up my CPU resources as soon as I launch VS Code. It will not stop if I quit VS Code, so when launching VS Code, quitting, and relaunching, I'll have 2 of those processes.

  PID TTY           TIME CMD
 9988 ??         1:14.31 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper

If I kill Code Helper, it seems to not affect the running VS Code instance.

Any suggestion?

// edit
After a uninstall using CleanMyMac, reinstall and opening my usual workspace the problem disappeared until I started to work, opening files, saving changes. The Code Helper process reappeared. So it doesn't seem to be related to extensions.

[bkniffler]

Okay, I found a work-around after reading #10735 which seems related to this problem.
You can remove Visual Studio Code.app/Contents/Resources/app/extensions/typescript folder entirely and the process will not appear.

Obviously this is not a solution, especially not for people who use typescript.

[tht13]

I have had problems with the insider builds over the last 2-3 days where the editor freezes while I am editing typescript files. It usually begins lagging during the linting process. I thought this might have to do with some typescript refactor/import helper tools I have installed but removing these hasn't helped.

[joaomoreno]

cc @dbaeumer

[konradhalo]

Yesterday i've added sass-lint extension and also CPU usage of Code Helper skyrocketed. I don't know if this is an issue with the linter itself or Code.

PID TTY           TIME CMD
  693 ??       167:21.66 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Users/konrad/.vscode/extensions/glen-84.sass-lint-0.0.1/node_modules/vscode-languageclient/lib/utils/electronForkStart /Users/konrad/.vscode/extensions/glen-84.sass-lint-0.0.1/server/server.js

[jpap]

Had the same issue; it was the Sass Lint (glen-84.sass-lint) extension for me. @jmhmd's suggestion of having UI to tell which extension has gone haywire is a great one. I'd love to see this included in the extensions panel!

[mjbvz]

If anyone is seeing this sort of issue while working on JS/TS projects, please take a look at this bug which has been known to spike the extension host CPU: microsoft/TypeScript#14636 The workaround is to make sure any tsconfig.json or jsconfig.json has an include or files configuration We're looking into a fix on the TypeScript side this month

If you try the workaround but still see this issue while working with JS/TS, please open a new bug and we can take a look

[glen-84]

@konradhalo @jpap

The issue with the sass-lint extension should be fixed in v0.0.4.

Apologies for the inconvenience.

[Mellbourn]

For me Code Helper spikes if I open my home folder. That folder contains a lot of files, since all my git projects are subfolders. Disabling extensions makes no difference

[alexdima]

This issue looks like a hot potato and it seems like I'm the one stuck with it for now :)

After a re-read, to summarise:

• sometimes the extension host process does not terminate or goes to >= 100% CPU.
• this cannot be reproduced when running code --disable-extensions.
• this is caused by extensions (built-in or installed from the marketplace)
• some of the extensions causing this high CPU usage have been identified and they have been fixed.

Most simple repro:

• write an extension that has a while(true) {} loop

I propose a somewhat realistic change:

• ship with a watchdog mechanism that will kill unresponsive / run-away extension host processes. Not amazing, but doable. Let's track this in Implement a watch-dog mechanism which can kill runaway extension host processes #26445.

Some other realistic things we could do:

• indicate in the UI which extensions are activated (have code and have been loaded)
• have a simple way to attach a debugger to the extension host, such that we can find out in what extension the execution is stuck. @weinand @bpasero is this doable?

[chrmarti]

Maybe we could automate the instructions I came up with in #11963 (comment).

[bpasero]

The extension host can be started in debug mode easily but you have to do it from the command line when starting VS Code, not when it is already running:

code --debugBrkPluginHost=<port> or code --debugPluginHost=<port>

[sjelfull]

One thing I've noticed that might or might not be a pattern: When switching from/to a external screen, it often triggers a 99% CPU usage. This might be the php extension, or it might be something else.

[skhilko]

Just filed a bug ☝️ for vscode-code-cover extension bmeck/vscode-code-cover#12. Apparently, it was breaking User Setting page in Visual Studio Code. Also, it seems like the same issue with git extensions went away for me once I uninstalled code coverage extension.

Might be helpful for somebody watching this thread.

[burness]

I have met the same issue when I run py files and I also open the user settings @sjelfull mentioned.

[Helcaraxan]

Hello there. Joining in on this old yet active thread.

I have been experiencing exactly the same CPU & battery burning behaviour over the last 1 or 2 months with VSC on my MBP 2016. Unfortunately I cannot recall at what point exactly it started appearing or what particular thing I did to VSC at that time.

Initial observations and first fix attempts

After having read through the discussions here as well as in duplicates / similar GitHub issues I have applied all suggested solutions I encountered without any effect though:

• updated my go tools (as this was mentioned somewhere and I use VSC for Go quite a lot).
• disabled Git support.
• disabled / uninstalled my Markdown extension.
• looked for other culprit extensions by disabling them one-by-one, quitting and restarting VSC, before checking the CPU again.
• starting VSC with --disable-extensions.

Even when disabling extensions I still have one of the Helper processes of VSC burning at ~130/150% CPU. Killing it does not help as it is respawned instantly with the same CPU burn.

This is eating up my battery in a small 1 to 2 hours (!!) where as I was used to having 6/8 hours easy while coding before. Putting in this last data point just to emphasise how painful this issue is.

Below a screenshot of top -pid <1> -pid <2> ... with all the PIDs in the VSC process-tree:

I am willing to provide any other kind of tracing or whatsoever is helpful.

Context

All this was done with a project managed via Git and containing a large variety of different languages and tools, most for which I have extensions installed (C/C++, C#, Java, Scala, Go, Typescript, Markdown, Bash, Protobuf, CMake, Bazel, SWIG). However I only had C/C++ and Go files open in my VSC editor at the time of trying out the above action points.

Extension list:

DevonDCarew.bazel-code@0.1.6
austin.code-gnu-global@0.2.2
dbankier.vscode-instant-markdown@1.1.0
lukehoban.Go@0.6.62
ms-vscode.cpptools@0.12.0
ms-vscode.csharp@1.11.0
redhat.java@0.7.0
twxs.cmake@0.0.17
vector-of-bool.cmake-tools@0.10.1
vscodevim.vim@0.9.0
waderyan.gitblame@1.11.3
zhutian.swig@0.0.5
zxh404.vscode-proto3@0.1.1

Further observation

I have been able to reproduce this behaviour (i.e with extensions disabled) in some projects but not in others. It seems like it is somewhat related to the size of the project. After testing on 10 different projects (GitHub or other):

• Repo size on disk > 750 MB - Reproducable (2 projects, 850MB and 1.5 GB)
• Repo size on disk < 750 MB - Not reproducable (8 projects, one around 500 MB and the rest below 200 MB)

These are of course very rough and low accuracy estimates but it does look like a trend.

Given that I can even observe this without any extensions enabled this looks to be a serious bug in VSC itself and not some badly coded third-party plugin.

[alexdima]

@Helcaraxan

To help us figure out which area is to be blamed, is it possible for you to find out the command line arguments of the process that goes CPU crazy (it could be: the file watcher process, the extension host process, the search service process, the renderer process, the main process, etc.) ... (I've used htop in the past to figure out the full process command line).

[Helcaraxan]

@alexandrudima I'll have a look when I can in the very near future. From the top of my head it was the extension host process.

[Helcaraxan]

@alexandrudima below is a screenshot, so it is actually the (file, I guess) watcher service.

[alexdima]

@bpasero I remember we used to have an option to turn off file watching, do we still have that?

@Helcaraxan The only thing I found is files.useExperimentalFileWatcher, maybe you can try setting that to true to see if the situation improves for your workspace. Additionally, you could use files.watcherExclude to exclude resources such as build artefacts, etc. Please let us know how it goes.

[bpasero]

@alexandrudima that is somewhat possible by setting:

"files.watcherExclude": {
    "**": true
}

[Helcaraxan]

@alexandrudima Using the experimental file-watcher did indeed remove the process going wild.

After rebooting with the option VSC took about 5 minutes burning full CPU (for file indexing probably) and another 10/15 minutes for the C++ extension to do some work. But after that no further CPU burn occurred.

This is however a recurring start-up behaviour so I'd better not close any windows to often.

[bpasero]

That would be #3998 (high CPU with our classical file watcher).

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.

[nikoanzai]

Great job vscodebot. This is a serious issue that forces me to switch back to Atom.

[mjbvz]

If you are still seeing high cpu usage, please open a new issue. There are multiple possible root causes of issue like this and it is generally much more productive to track each case separately