microsoft / vscode

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

File watcher consumes lots of CPU in large TS projects #214567

Closed kamax1 closed 4 months ago

kamax1 commented 4 months ago

Type: Performance Issue

Hello! After latest update vscode stared using 100% cpu for each window. I found that it caused by fileWatcher process. I have a very large project but it was fine before the update. Could you fix it pls. Thanks!

VS Code version: Code 1.90.0 (Universal) (89de5a8d4d6205e5b11647eb6a74844ca23d2573, 2024-06-04T19:34:44.157Z) OS version: Darwin arm64 23.4.0 Modes:

System Info |Item|Value| |---|---| |CPUs|Apple M3 Pro (12 x 2400)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled| |Load (avg)|4, 4, 4| |Memory (System)|36.00GB (2.59GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|
Process Info ``` CPU % Mem MB PID Process 2 221 95859 code main 0 111 95860 gpu-process 0 37 95861 utility-network-service 0 848 95862 window [1] (file1.ts — project1) 0 627 95863 window [2] (file2.ts — project2) 0 147 96052 shared-process 100 922 96053 fileWatcher [2] 101 958 96065 fileWatcher [1] 0 295 96155 extensionHost [2] 0 147 96174 electron-nodejs (tsserver.js ) 0 2175 96177 electron-nodejs (tsserver.js ) 0 74 96429 electron-nodejs (typingsInstaller.js typesMap.js ) 0 74 96282 electron-nodejs (eslintServer.js ) 0 74 96283 electron-nodejs (ya-make-lsp.js ) 0 111 96284 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Plugin).app/Contents/MacOS/Code Helper (Plugin) /Users/buckster/.vscode/extensions/streetsidesoftware.code-spell-checker-3.0.1/packages/_server/dist/main.cjs --node-ipc --clientProcessId=96155 0 74 96285 electron-nodejs (start-server.js ) 0 74 96960 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Plugin).app/Contents/MacOS/Code Helper (Plugin) /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/json-language-features/server/dist/node/jsonServerMain --node-ipc --clientProcessId=96155 0 74 96156 ptyHost 0 0 96162 /bin/zsh -il 0 0 96163 /bin/zsh -il 0 0 96168 /bin/zsh -il 0 295 96157 extensionHost [1] 0 147 96197 electron-nodejs (tsserver.js ) 0 2212 96198 electron-nodejs (tsserver.js ) 0 74 96412 electron-nodejs (typingsInstaller.js typesMap.js ) 0 221 96290 electron-nodejs (eslintServer.js ) 0 74 96294 electron-nodejs (ya-make-lsp.js ) 0 258 96296 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Plugin).app/Contents/MacOS/Code Helper (Plugin) /Users/buckster/.vscode/extensions/streetsidesoftware.code-spell-checker-3.0.1/packages/_server/dist/main.cjs --node-ipc --clientProcessId=96157 0 74 96297 electron-nodejs (start-server.js ) ```
Extensions (18) Extension|Author (truncated)|Version ---|---|--- vscode-eslint|dba|2.4.4 EditorConfig|Edi|0.16.4 pi-helper|ela|0.0.41 prettier-vscode|esb|10.4.0 vscode-language-pack-ru|MS-|1.89.2024050109 remote-ssh|ms-|0.110.1 remote-ssh-edit|ms-|0.86.0 remote-explorer|ms-|0.4.3 sftp|Nat|1.16.3 vscode-yandex-arc|per|0.277.0 code-spell-checker|str|3.0.1 code-spell-checker-russian|str|2.2.2 vscode-stylelint|sty|1.4.0 language-stylus|sys|1.16.0 errorlens|use|3.18.0 intelliboba|vik|0.9.8 sync-rsync|vsc|0.36.0 pretty-ts-errors|Yoa|0.5.4
bpasero commented 4 months ago

Is this with a TypeScript workspace? Does it get better if you configure typescript.tsserver.experimental.useVsCodeWatcher: false?

kamax1 commented 4 months ago

Is this with a TypeScript workspace? Does it get better if you configure typescript.tsserver.experimental.useVsCodeWatcher: false?

Yep, i have a ts project. That setting really helped, thanks)

bpasero commented 4 months ago

@kamax1 would I be able to reproduce this issue if you gave me instructions how to get to the same workspace?

kamax1 commented 4 months ago

@kamax1 would I be able to reproduce this issue if you gave me instructions how to get to the same workspace?

unfortunately, i'm not able to share my repo. But i've reproduced it on several large projects so i suppose that it should be reproducable on any large TS project (mine have ~40k files)

bpasero commented 4 months ago

@kamax1 it cannot be so obvious to reproduce though, VS Code is a fairly large TS project where I am not seeing it (also as far as I know, not anyone from our team).

Is it possible there are any cyclic symbolic links in your workspace?

smishenk commented 4 months ago

+1 for this issue.

I'm working on a huge TS project and Remote-SSH to it from MacOS laptop to Linux machine. Started having troubles since 1.89 version (downgrade to 1.88 solved the problem): VSCode becomes "unresponsive" quite fast - as soon as TS features finish initialization, IDE fails to open any other files/directories, progress bars at the top of file editor and explorer run indefinitely. Also, it somehow seems to be related to arm-based MacOS laptops, cause I only encounter this issue on my MacBook Air M2, while MacBook Pro 19 with Intel processor didn't run into any issues even with 1.89 version. Although I can't confirm that experimental watcher was enabled on Intel Mac last time I checked and I'm not able to re-test it anymore. Anyway, only those of my colleagues who are on arm-based Macs complained.

Is it possible there are any cyclic symbolic links in your workspace?

Speaking of my project - yes, it's highly possible. Yet, I cannot say for sure.

Does it get better if you configure typescript.tsserver.experimental.useVsCodeWatcher: false?

Solved the problem for me as well

bpasero commented 4 months ago

Can people that are impacted here do the following:

This will print information about how many requests for file watching were sent to the file watcher process. I would expect this to be in the number of thousands.

smishenk commented 4 months ago

Can people that are impacted here do the following:

  • open said workspace in VS Code (ensure typescript.tsserver.experimental.useVsCodeWatcher is configured to true)
  • wait for the file watcher process to have settled to 0% (this can take time)
  • run "Developer: Set Log Level..." and pick "Trace"
  • open the "Output" panel
  • from the dropdown pick "File Watcher" channel
  • Copy the output you see into a response here

This will print information about how many requests for file watching were sent to the file watcher process. I would expect this to be in the number of thousands.

In my case it only displays local file watchers/requests. Either because it does not trace remote-SSH processes at all or it cannot get info from VSCode server since that connection "hangs up". Any other ideas how I may trace this data from remote VSCode server?

bpasero commented 4 months ago

Oh yeah sorry, I forgot that it will only report local watchers...

kamax1 commented 4 months ago

@kamax1 it cannot be so obvious to reproduce though, VS Code is a fairly large TS project where I am not seeing it (also as far as I know, not anyone from our team).

Is it possible there are any cyclic symbolic links in your workspace?

Yes, looks like so, with have a lot of symlinked packages and looks like some of them are cycled

bpasero commented 4 months ago

There was 1 performance related fix for file watching pushed yesterday that is included in our insiders build today. I would be curious if people could try it out and report back. You can give our preview releases a try from: https://code.visualstudio.com/insiders/

smishenk commented 4 months ago

There was 1 performance related fix for file watching pushed yesterday that is included in our insiders build today. I would be curious if people could try it out and report back. You can give our preview releases a try from: https://code.visualstudio.com/insiders/

I've checked insiders build on my project. Unfortunately, the issue is still there :(

bpasero commented 4 months ago

@smishenk when you say its a huge project, does it have many TS projects inside?

smishenk commented 4 months ago

@smishenk when you say its a huge project, does it have many TS projects inside?

Well, it does have some TS subprojects, yet I don't think that it matters in any way, cause the main part (~85% of TS code) is single TS project and, as I see in VSCode footer, TS server initializes separately for each opened project, while I have issues right after initialization of main part.

When I say it's a huge project, I say we have to raise memory consumption limit for TS server up to 6 Gb: "typescript.tsserver.maxTsServerMemory": 6144 Otherwise, TS server fails to start x)

bpasero commented 4 months ago

@smishenk is that project open source for me to play with?

Does the CPU eventually settle or stay high?

smishenk commented 4 months ago

@smishenk is that project open source for me to play with?

You would have a link already, if it was ;)

Does the CPU eventually settle or stay high?

I can't say anything about that for now, cause I have issues with remote SSH development. Local CPU does almost nothing and I cannot profile remote machine since SSH connection hangs up the moment VSCode loads it with its processes. I'll try to reproduce the same behavior locally later and collect profile info you asked about.

smishenk commented 4 months ago

@bpasero I couldn't reproduce the same behavior locally, so it seems that this issue isn't related to the size of a project. The only difference between my local repo and remote is that remote has symlinked directories (and I can't do anything with that, cause this is how our projects are organized on dev-machines). Anyway, I managed to profile dev-machine using top and here are some results:

I'm wondering if I could enable some tracing/logs of TS server on remote-SSH to get detailed info

bpasero commented 4 months ago

/duplicate https://github.com/microsoft/vscode/issues/216825

vscodenpa commented 4 months ago

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.

Happy Coding!