search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.26k stars 29.3k forks source link

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

Closed rdwoodring closed 5 years ago

rdwoodring commented 5 years ago

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 (a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4, 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

mjbvz commented 5 years ago

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

rdwoodring commented 5 years ago

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

Capture
rdwoodring commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

image

bpasero commented 5 years ago

@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 commented 5 years ago

image

bpasero commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

Oh wow, ok: https://github.com/electron/node/pull/70#issuecomment-475187060

rdwoodring commented 5 years ago

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

bpasero commented 5 years ago

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

shiftkey commented 5 years ago

Bumping this discussion to indicate this probably requires a fix to Electron's node to address the Cannot read property 'close' of undefined issue https://github.com/electron/node/pull/97

jineshkj commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/electron/node/pull/97. Once VSCode is able to update to this version, things should be sorted.

todonovan commented 5 years ago

Great, thanks!

bpasero commented 5 years ago

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

RobertBlackhart commented 5 years ago

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 commented 5 years ago

Closing based on comments.