High CPU Usage on Windows with Mapped Drive when leaving VS Code Open for a while

[rdwoodring]

Issue Type: Performance Issue

1. Open a large folder from a mapped drive in VS Code
2. Work in VS Code for a while, or just leave it open

Expected Outcome
CPU might spike during use, but should drop back down

Actual Outcome
CPU spikes and stays up in the double digits, often as high as 60-80%, causing the editor and other apps on the machine to be almost unusable.

VS Code version: Code 1.32.3 (a3db5be, 2019-03-14T23:43:35.476Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz (4 x 2195)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: enabled surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Memory (System)	7.91GB (0.77GB free)
Process Argv
Screen Reader	no
VM	0%

Process Info

CPU %	Mem MB	   PID	Process
   16	    76	 10668	code main
    0	    60	  5324	   shared-process
   31	   299	  8124	   window (Picker.js - Visual Studio Code)
    0	    31	  5488	     searchService
    0	    11	 11840	     electron-crash-reporter
    0	   152	 18992	     extensionHost
    0	    25	  5984	       "C:\Program Files\Microsoft VS Code\Code.exe" "c:\Program Files\Microsoft VS Code\resources\app\extensions\html-language-features\server\dist\htmlServerMain" --node-ipc --clientProcessId=18992
   23	   352	  8808	       electron_node tsserver.js 
    0	    58	 11072	       electron_node eslintServer.js 
    0	    14	 22128	     watcherService 
    0	     5	 13004	       console-window-host (Windows internal process)
    1	    67	 13880	   window (Issue Reporter)
    1	   479	 14708	   gpu-process

Workspace Info

|  Window (Picker.js - Visual Studio Code)
|    Folder (Acadia): 12555 files
|      File types: html(5570) js(3688) map(1134) java(515) png(448) cfm(259)
|                  less(185) htm(161) cfc(102) snap(100)
|      Conf files: package.json(2) gulp.js(1) webpack.config.js(1)
|                  launch.json(1) settings.json(1)
|      Launch Configs: node(2);

Extensions (19)

Extension	Author (truncated)	Version
vscode-nsp	ada	1.0.1
vscode-eslint	dba	1.8.2
xml	Dot	2.4.0
coldfusion	ili	1.0.1
backbone-js-snippets	ioa	0.0.1
docthis	joe	0.7.1
prettify-json	moh	0.0.3
mssql	ms-	1.4.0
sublime-keybindings	ms-	4.0.0
debugger-for-chrome	msj	4.11.3
java	red	0.40.0
vscode-sort-json	ric	1.13.0
vscodeintellicode	Vis	1.1.4
vscode-java-debug	vsc	0.17.0
vscode-java-dependency	vsc	0.3.0
vscode-java-pack	vsc	0.6.0
vscode-java-test	vsc	0.15.0
vscode-maven	vsc	0.15.1
cordova-tools	vsm	1.8.0

[roblourens]

Could you look at the tips on this page and provide more details to help us understand what's happening? https://github.com/Microsoft/vscode/wiki/Performance-Issues#visual-studio-code-is-consuming-a-lot-of-cpu

Have you seen this before on earlier releases?

[rdwoodring]

First I've hit it is on 1.32.x (i think 1.32.0, but maybe 1.32.1). I'll read through the tips, and keep an eye on process explorer. Will update, but might not be until Monday as I'm getting ready to wrap up for the day and haven't tried to repro on my home computer

[rdwoodring]

So, I left VS Code running over the weekend and didn't shut my laptop down. I came in this morning and checked VS Code's Process Explorer (screenshot attached). The CPU usage for extension host seems like a non-issue, so guessing this isn't an issue with an extension? Though the way "electron_node tsserver.js" is intended maybe it's an extension. In any case, it doesn't look like one I've installed. Happy to try running with extensions disabled later today if you think that'll help, but looks like the main culprit is renderer/window process. Tried to profile CPU but it's so bound up at the moment that I can't get dev tools to respond. Going to try to get a profile later this afternoon once CPU starts to spike again.

[mjbvz]

Does this reproduce in the latest VS Code insiders build with all extensions disabled?

[rdwoodring]

@mjbvz I can install that and check it out tomorrow. Still trying to get a CPU profile, but when I encounter this my laptop is so slammed that I can't get much out of the dev tools. Trying to grab a profile now and having trouble, but, I did notice that I am getting thousands of console errors (see attached). As mentioned in the OP, my project is on a mapped network drive and I just reproduced the issue at home on my work laptop without being connected to the work VPN (so, no access to the mapped drive). So, basically, I left my laptop on with VS Code open, and just closed the laptop, then came home and reopened the laptop with VS Code still open and no access to the mapped drive.

I'm wondering if this has something to do with VS Code trying to index files or something and being unable to read the files. Tried to include the stack trace there in the screen shot, but, like I said, CPU is super slammed and it was a chore to even get the error to expand.

[rdwoodring]

I can reproduce the issue on the Insiders Build with extensions disabled.

Pretty confident it's related to losing the mapped drive. I'm connected to the work network on Wi-Fi and can reproduce pretty easily on Insiders and 1.32.x.

Updated Steps:

1. Have a network drive mapped to a local computer
2. Open a project/folder in VS code from the mapped drive
3. Lose the mapped drive by killing wi-fi or VPN
4. Try to open a file from the VS Code file Explorer

CPU spikes up to double digits (for me) and stays there. thousands of errors (see previous comment) in the console. CPU does not go back down when the network drive is reconnected.

Let me know if there's more info I can provide.

[bpasero]

@rdwoodring can you possibly attach all the logs from VSCode, those errors look interesting. Also can you run a session with --verbose and then attach the logs, maybe there is more detail. The logs folder can be opened from the commands "Logs Folder".

[zspitzer]

the problem is the null check here, this._handle is undefined, not null

[bpasero]

@zspitzer is it possible that you are not on the latest VSCode version? That source code looks like from node.js which does not match our current sources.

[zspitzer]

[bpasero]

@deepak1556 may I ask if you have any clue where this code lives in Electron? The check certainly seems fishy to me to check for null and not undefined...

[bpasero]

@deepak1556 wow it looks indeed like this code lives in https://github.com/electron/node/blob/fcaf11a29c421b0e76c9f24f5b155a53eff14e7f/lib/fs.js#L1383. How is it possible that the Electron version of node differs from the one official one?

[bpasero]

Oh wow, ok: electron/node#70 (comment)

[rdwoodring]

20190321T081202.zip
@bpasero Logs attached. Regular logs had nothing, but looks like the errors got picked up once I ran with --verbose.

[bpasero]

Thanks, yeah again many of TypeError: Cannot read property 'close' of undefined

[shiftkey]

Bumping this discussion to indicate this probably requires a fix to Electron's node to address the Cannot read property 'close' of undefined issue electron/node#97

[jineshkj]

I see this issue has been quiet for a while now. This is a problem that I face every day, so any workaround that anyone can suggest will be highly appreciated.

[todonovan]

Also facing a severe performance issue with this -- 90% CPU usage , high mem + mem leak. Opening Dev Tools console shows an endless stream of FsEvent.FsWatcher._handle.onchange errors -- in the 20 minutes I've had the console open I've received over 400,000 of them. It's unfortunately making code unusable now.

I haven't been able to precisely repro the issue yet, but the steps outlined above are essentially what I experience. It only started occurring in a relatively recent update, and tends to occur after waking the PC from sleep. PC wakes up and I find the code window completely unresponsive, with the above errors streaming in. (I've received another 50,000 errors in the time it's taken me to write this paragraph).

Appreciate the work so far, it appears to be an issue upstream w/ Electron. Hope to see a fix flow down to code soon so I can resume using my favorite editor.

[shiftkey]

Appreciate the work so far, it appears to be an issue upstream w/ Electron.

Electron 3.1.8 has been released with the bugfix from electron/node#97. Once VSCode is able to update to this version, things should be sorted.

[todonovan]

Great, thanks!

[bpasero]

@shiftkey @todonovan we already updated in our insider builds. You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[RobertBlackhart]

Thanks. This has been bugging me as well for a while now since I operate out of a mapped network drive and change my connectivity from wired to wireless quite often as I move about the office.

The latest insiders build (1.34.0 with Electron 3.1.8) seems to fix the issue as mentioned.

Another symptom that I assume was related was that when a disconnect/reconnect happened, the explorer pane would no longer track added or removed files unless I manually clicked the refresh button. That also seems to be working correctly after the fix.

Edit: nevermind that last point. That still seems to happen.

[bpasero]

Closing based on comments.