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

Created on 11 Aug 2016  ·  77Comments  ·  Source: microsoft/vscode

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

Steps to Reproduce:

  1. Open my project

  2. image

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.

bug extension-host freeze-slow-crash-leak needs more info

Most helpful comment

Just had the same issue... VS Code running, with a project open. Not doing anything with VS Code, but "Code Helper" process was running in the background at 99% CPU usage and my fans were going crazy.

MacBook Pro: macOS 10.12.1

All 77 comments

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

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

image

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:

image

@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...

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 :)

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%.

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

@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.

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...

@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?

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/

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

@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.

@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...

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

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.

Okay, I found a work-around after reading https://github.com/Microsoft/vscode/issues/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.

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.

cc @dbaeumer

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

The extension host using a lot of CPU was again reported by @pitAlex in #11963.

Reading through this I am pretty sure that this is not caused by the TS support shipping with VS Code. The actual TS language smartness runs in its own process. If TS would make the extension host causing high CPU then the tsserver must run on high CPU as well. At the end all the TS extension code running in the extension host does is converting data structures. Assuming it would receive huge amount of data then this hugh amount would come from the tsserver which as said would require equal high CPU load there as well.

There was a bug in the tslint extension that causes the linter to lag. However that got fixed a while ago and did not affect typing in the editor.

@jrieken were are we with the support you experimented with to profile the extension host. That would definitelly help tracking this down.

@dbaeumer I agree. All we know at this point is that there is an extension activated in the extension host process that eats a lot of CPU.

I can say that in my case, having files.watcherExclude be the same has files.exclude has drastically reduced the number of times code helper with randomly get high. In fact it hasn't happened once since my last post in #11963.

I can see this issue with VSC 1.6.0 on macOS Sierra

I've tried VCS 1.6.1 on macOS Sierra, remove typescript folder , then Code Helper still get CPU high.

After remove typescript, the process looks like this

ps -ef|grep 71749
  501 71749 71664   0 11:31上午 ??         0:51.39 /private/var/folders/lq/s01sr4413nnc9zpn8y8705w40000gn/T/AppTranslocation/08F7263B-5AB6-4CC0-91C9-E9C2DCD01AE6/d/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /private/var/folders/lq/s01sr4413nnc9zpn8y8705w40000gn/T/AppTranslocation/08F7263B-5AB6-4CC0-91C9-E9C2DCD01AE6/d/Visual Studio Code.app/Contents/Resources/app/out/bootstrap --type=watcherService

@bpasero the process @dove-young is referring to is the watcher process --type=watcherService

@dove-young is the workspace you are using containing large folders with many files?

@bpasero No. There was just a single markdown file, such as kind of Readme.md. A few hundred lines.

@dove-young so you say you open just a single markdown file in Code and the CPU spins high? Can you attach this file?

I don't know how to attach files in the comments. But you can fetch it from project https://github.com/spf13/spf13-vim .

It happens when open the project folder of spf13-vim, click the README.markdown and preview.

@dove-young I just tried and CPU is totally normal for me.
I wonder if this issue is being caused by an installed extension. Can you try to run VS Code without extensions? From the command line (NOT the integrated terminal in Code), execute: code --disable-extensions and try your steps again to see if it reproduces. If you see it is an issue with the extension, please file it against the extension repository itself.

I've also tried the repository on Windows, and I also don't get high CPU usage.

Had the same problem, uninstalled
dbankier.vscode-instant-markdown
and the problem seems to be gone.

OSX Sierra with vscode 1.7, a golang project with the golang extension. I don't recall having this issue with earlier versions.

Forgot to mention I don't seem to have this issue with typescript projects.

renderer?

for i in `ps -ef | grep Code | awk '{print $2}'`                                                                                                                                                                  
do
ps -p $i
done
  PID TTY           TIME CMD
  253 ??         0:00.10 /System/Library/Frameworks/Security.framework/Versions/A/XPCServices/com.apple.CodeSigningHelper.xpc/Contents/MacOS/com.apple.CodeSigningHelper
  PID TTY           TIME CMD
 3979 ??         0:09.06 /Applications/Visual Studio Code.app/Contents/MacOS/Electron .
  PID TTY           TIME CMD
 3989 ??         0:02.45 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --type=gpu-process --channel=3979.0.1970996391 --mojo-application-channel-token=E553C1D456DF2EF09F50D43DB24F3C9E
  PID TTY           TIME CMD
 4008 ??         0:00.52 /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=SharedProcess
  PID TTY           TIME CMD
 4009 ??         0:26.91 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --type=renderer --no-sandbox --primordial-pipe-token=E303B05568F676938D15E4F5A2CF394D --lang=en-US --node-integr
  PID TTY           TIME CMD
 4010 ??         0:00.97 /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
  PID TTY           TIME CMD
 4012 ??         0:00.01 /Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --database=/tmp/VSCode Crashes --url=https://ticinocrashreporter.azurewebsites.net/crash --handshak
  PID TTY           TIME CMD
 4015 ??         0:00.33 /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=watcherService
  PID TTY           TIME CMD
 4019 ??         0:00.34 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap /usr/bin/git /Users/mhaan/AppDev/go/sr

@sfrooster The renderer is quite easy to profile. Can you please do the following to find out where the time is spent:

  • F1 > Developer: Toggle Developer Tools
  • go to Profiles
  • begin recording the JS CPU of the main thread
  • do the steps that cause high CPU - I suggest keeping it to a small length, otherwise it is hard to analyze the results if you end up doing too many different things.
  • stop recording
  • try to save the profile and attach it here -- this might fail, there is an issue with the current Electron version where saving the profile results in a 0 bytes file -- in that case close-up screenshots of where the time is spent would be helpful

profile

Having the same issue.

screen shot 2016-11-17 at 10 58 39 pm

Upgrading go tools seemed to fix things for me.

On Thu, Nov 17, 2016, 8:01 PM Matt MacPherson [email protected]
wrote:

Having the same issue.

[image: screen shot 2016-11-17 at 10 58 39 pm]
https://cloud.githubusercontent.com/assets/8339427/20418223/ae4d24e0-ad19-11e6-9780-e472fefab8b1.png


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/10439#issuecomment-261443539,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-vl54G4s7BkUE_daRIb7dkTO4Lbpqtks5q_SMKgaJpZM4JiWAe
.

Just had the same issue... VS Code running, with a project open. Not doing anything with VS Code, but "Code Helper" process was running in the background at 99% CPU usage and my fans were going crazy.

MacBook Pro: macOS 10.12.1

I only have a handful of extensions. I resolved the issue by disabling the SASS Lint extension. I have seen other issues discussing this and it seemed many of the discussion pointed to Electron. I am not seeing this issue with any other linting extensions, like ESLint.

I've been seeing the same the last month or so.

VS Code version: 1.8.1
OS X: 10.12.1

This is the line that is currently using 100% CPU:

fred              9122 100.0  0.1  3279588   9124   ??  R     8:14PM 167:34.46 /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

Is there a way to figure out which extensions is actually causing the usage? Maybe a method to debug it should be added somehow?

I didn't read carefully enough to see that #11963 was considered a duplicate of this one. I've posted the following three reports in there over the last few days:

On Feb 20:
I've been seeing this problem lately too. The most recent instance is with this process:

/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/typescript/node_modules/typescript/lib/typingsInstaller.js --globalTypingsCacheLocation /Users/danny/Library/Caches/typescript --enableTelemetry

Sometimes it's a different one, but this seems to be the most usual culprit.

On Feb 21:
This morning, I have two processes each consuming 99-100% of a core. Both have these details:

/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/typescript/out/utils/electronForkStart /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/typescript/node_modules/typescript/lib/tsserver.js --useSingleInferredProject --enableTelemetry

Today (Feb 23):
Today, I have these two processes. The first is running the CPU at about 125% (didn't think that was possible). The second is keeping the CPU around 90%:

/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/typescript/node_modules/typescript/lib/typingsInstaller.js --globalTypingsCacheLocation /Users/danny/Library/Caches/typescript --enableTelemetry

/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/typescript/out/utils/electronForkStart /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/typescript/node_modules/typescript/lib/tsserver.js --useSingleInferredProject --enableTelemetry

Is anybody still looking at these problems? I might have to consider going back to Sublime Text or giving Atom a try if Code keeps pegging my CPUs.

It is really easy for me to spin up a Code Helper process consuming 99.9% CPU when I want 😄 This is one of the ways to reproduce the issue consistently.

  • Open any file for editing
  • Cmd + p
  • Select Git: View File History
  • Select any version of the file
  • Select View File Contents

After that I see the infamous Code Helper process in Activity Monitor. "Git: View File History" doesn't work anymore. The only cure is to exit VSC and kill the process manually.

To @dannylevenson point, I have two guys on my team switched to WebStorm because of this problem. I wonder why this is not the high priority bug for VSC team?

@dannylevenson Can you please open a new issue for the TypeScript specific perf probolems. To help us investigate, please try collecting the log from the TypeScript server by:

  1. Exit VSCode
  2. Set the TSS_LOG log environment variable

    • For bash on Mac for example:

      $export TSS_LOG="-level verbose -file /Users/${username-`whoami`}/tss.log"

  3. Start VS Code with extension disabled from an environment with TSS_LOG set, by running $ code --disable-extensions for example
  4. Reproduce the problem
  5. Share the tss.log file

Thanks

@sjelfull Could you try with the latest version (currently 1.9.1), 1.8.1 has some known issues that are fixed in 1.9.

@skhilko The "Git: View File History" action you mention is from an extension, please file a bug report with them.

@chrmarti you're right "Git: View File History" action is coming from Git History extension. I was under impression that was a built in feature.

That lead me to explore some other git extensions. I've installed GitLens and selected "Git Lens: Compare with Previous Commit" on one of the files in my repo. Same thing here, Code Helper process spun up 99% CPU load.

This coincidence makes me wonder, are these extensions poorly developed? I can't believe that it is so easy to hang the editor from the extension. Could there be something wrong with VSC framework?

@skhilko There is no API for SCM/Git other than Git itself. What version of VSCode and which OS are you running on? Please still open bug reports with the extensions so they can come back to us in case it's something on our side.

@chrmarti Thanks, I'll open bug reports with them.

I'm running VSC v1.9.1 on macOS Sierra (v10.12.3)

@chrmarti I tried 1.10.0 (Insiders version), and it still happens there. Anything I can do to give you more information

@sjelfull Could you tell me which process it is and what it's command line arguments are? What are the extensions your are using (Help > Report Issues will give you the full list)? Does the problem persist if you start VSCode with --disable-extensions (quit the application first)?

I wonder if --disable-extensions disables the built-in git support. Anyways I had these High CPU usage issues many times a day and almost gave up on VSCode but then I added this to my Settings : "git.enabled": false and now it's been 2 days without any issues. Loving it ... ;)

I love VS Code, but am finding this CPU problem really kills my iMac.

screen shot 2017-03-10 at 10 45 29pm

The funny thing is that my partner is working on the same project I am (PHP, JS, web development) and has seen nothing of the sort. My machine is iMac (Mid 2011), his is iMac (Mid 2013). I wonder if there is something about the architecture of the older iMac that drives Code Helper crazy?

If so, this may also make the problem harder for the VS Code team to track down. They might not see it on more recent hardware.

I'd say this might be an Electron issue, except that I move to Atom for a week and saw nothing like this CPU usage.

Even odder, though, is that this process hangs around long after I've quit VS Code. Here is my Activity Monitor 10 minutes after quitting VS Code:

screen shot 2017-03-11 at 12 38 15am

What is up with this?

I've had this same problem on a brand new Macbook Pro 2016, so seems unrelated to specific architecture. Tried disabling Git, problem still showed up. Disabling extensions seemed to solve the issue, but still have the problem of not knowing which extension causes it.
being able to tell which extension is pegging the CPU would be very helpful.

OS: MacOS v10.12.3
VSCode: v1.10.2

@efc Could you follow-up with the Docker extension in a bug report so they can look into it? /fyi @chrisdias

Sorry, @chrisdias. I have been trying to get this to repeat consistently and cannot do so. I've removed my previous comment about Docker since I think that may have been misplaced.

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!

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: https://github.com/Microsoft/TypeScript/issues/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

@konradhalo @jpap

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

Apologies for the inconvenience.

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

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 #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?

Maybe we could automate the instructions I came up with in https://github.com/Microsoft/vscode/issues/11963#issuecomment-294948281.

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>

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.

Just filed a bug ☝️ for vscode-code-cover extension https://github.com/bmeck/vscode-code-cover/issues/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.

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

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:

screen shot 2017-07-08 at 11 45 01

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:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

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.

@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).

@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.

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

screen shot 2017-08-10 at 16 52 36

@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.

@alexandrudima that is somewhat possible by setting:

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

@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.

That would be https://github.com/Microsoft/vscode/issues/3998 (high CPU with our classical file watcher).

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.

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

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

Was this page helpful?
0 / 5 - 0 ratings