BUG: High Energy Impact.

[awgeorge]

Not sure how I can help debug this, whilst code is running in the background, it has a detrimental effect on the performance of the battery.

[ccimage]

Also happened on my MAC, OSX10.11. What is the Electron Helper?

[bpasero]

This can be anything, from a plugin eating lots of CPU to the file watcher. Can you share more about the environment and project.

[awgeorge]

I have no additional plugins installed. Installed version of code: 7cc0c60 in a default state.

AutoSave is turned off.

OSX10.11

GIT is enabled for the current project.

The next time it triggers again, i'll make sure to log what i'm doing.

[bpasero]

Yeah the size and kind of workspace you open also plays a role.

[awgeorge]

The current project I'm working on is 100MB with 7,163 files mainly PHP. I have about 20 open in the working files

[bpasero]

I wonder if the PHP process we spawn for linting could have an impact, @aeschli is there a way to trace this?

[aeschli]

Are you on 0.10.2?
In 0.10.1 PHP has bug #160.

[awgeorge]

Currently 0.10.2 I can't be sure at which point I upgraded (unhelpful). It may have been recently. I can keep working to see if the issue returns.

While I didn't check the CPU, as the editor still worked absolutely fine it couldn't have been maxing out.

The only reason I noticed a problem was because the battery drained more rapidly than usual. I then checked and it had been running at 99.9 energy impact.

The editor itself was very responsive.

[aeschli]

With bug #160, the extension host process would run in an endless loop. The editor was not affected, but validation, intellisense and hover would not work anymore.

[awgeorge]

Fair enough - I can't say I would have missed those so could be the same issue. I'll check my other computers when I get back to make sure they are all running the latest 0.10.2

[bpasero]

Ok please reopen then if you still see it with latest.

[ccimage]

Still have this issue on 0.10.6. As usual i will open 2 project(folder), one is php and the another is javascript. How can i commit a log or other things in details?

[aeschli]

@ccimage What if you open only the JavaScript project? The JavaScript language service is doing real work as it needs to analyze and open potentially all files in folder and subfolders.

For PHP, did you configure the PHP command? If not. it should not consume much.

[ccimage]

@aeschli Sorry, i do not known the status about PHP command, actually i don't known what is this mean. I'm new on PHP.

[bpasero]

Can people seeing this issue with a JavaScript workspace please give our insiders build a try (https://code.visualstudio.com/insiders) and enable Salsa: https://github.com/Microsoft/vscode-docs/blob/master/release-notes/latest.md#javascript---salsa-preview

[chiangf]

@bpasero I see this issue with Insiders (0.10.8) and Salsa enabled, pretty consistently running at a high energy impact (OSX)

[chiangf]

Did a little poking around, in my project, I had a large dir that I had included in files.exclude and search.exclude, thinking that that would prevent processing on it. But after removing that large dir, my energy usage dropped dramatically.

[bpasero]

@chiangf can you please verify that adding the large dir to exclude really is the source of the high CPU use? does the CPU change just by making a change to this setting? If so, which one?

[chiangf]

@bpasero I think the high CPU use was definitely due to the large dir (it was a few gigs in size), which is understandable if the entire dir is being processed. After clearing out the large dir, the CPU use dropped instantly to a very normal amount.

But the large dir was in the list of files.exclude (and didn't show up in vscode), so I think the issue is that files in files.exclude are still being processed. Not sure if there's another setting to exclude it completely though.

[bpasero]

@chiangf I think the issue is that files.exclude does not prevent VS Code from going into that folder and ignoring it for file events. #3703 would help

[bpasero]

@awgeorge @ccimage @chiangf is one of you able to do a little experiment? I am speculating that maybe our library for file watching is failing. The steps would be:

• setup to run vscode out of our sources as described at https://github.com/Microsoft/vscode/wiki/How-to-Contribute
• copy the contents of Applications/Visual Studio Code.app/Contents/Resources/app/node_modules/chokidar into the sources at ./node_modules/chokidar (replace the entire folder)
• open ./node_modules/chokidar/lib/fsevents-handler.js from the sources and insert console.log('Do we have fsevents?: ', !!fsevents) in line 9
• open ./src/vs/workbench/services/files/node/watcher/unix/watcherService.ts from the sources and set VERBOSE_LOGGING to true in line 43
• make sure to recompile to pick up this change (e.g. run gulp watch and wait for it to finish)
• run code out of sources with ./scripts/code.sh
• from the window that opens show the developer console (Help | Toggle Developer Tools)
• check if you see [Service Library: Watcher] Do we have fsevents?: true

For me (since fsevents works ok), I get this:

If something goes wrong, I would expect fsevents to print as undefined. In that case, can you put another console.log inside the try/catch block of line 7 to see what the error is loading that native module?

Thanks!

[bpasero]

@awgeorge @ccimage @chiangf sorry my instructions from yesterday were not good and I have updated them.

[bpasero]

We found out about the issue and here is what happens:

• user opens a large folder in VS Code
• VS Code installs a watcher on the root of the folder from another process
• watcher starts to walk the folder in a way that memory increases a lot
• eventually the process dies with out of memory
• VS Code detects this and starts the watcher again because we typically never want to loose the watching information
• this goes on and on forever and simply results in constant and high CPU use

We also verified that chokidar was not falling back to polling.

The fixes for March are:

• allow the user to configure excludes from the new files.watcherExclude setting
• add node_modules to the excluded folders by default
• do not restart chokidar after 5 failing attempts

For the future, we are looking into #3998

[awgeorge]

👌🏼

Sent from my iPhone

On 11 Mar 2016, at 08:39, Benjamin Pasero notifications@github.com wrote:

Closed #774.

—
Reply to this email directly or view it on GitHub.

[baldmountain]

I may have some more information. I have a large project with many JavaScript files. I also usually have several Code instances open on different projects directories. I'm starting to get "Too many files open" errors and Code will become confused. Sections of the editor display won't update and CPU usage seems high. Restarting Code seems to clear things up. Could it be that Code is not closing files?

[bpasero]

I think for March this could be better, we reduce the number of open file watchers for working files and you have the option to exclude files from watching. I suggest we give March a try and you open a new issue if that does not help.