irm-codebase commented 2 months ago

Type: Bug

Opening a project using the 'New Window' will lock a CPU for around half a minute.

This behavior did not happen in the previous version in my system (I think 1.92?).

VS Code version: Code 1.92.2 (fee1edb8d6d72a0ddff41e5f71a671c23ed924b9, 2024-08-14T17:29:30.058Z) OS version: Linux x64 6.10.4-200.fc40.x86_64 Modes:

System Info

|Item|Value| |---|---| |CPUs|13th Gen Intel(R) Core(TM) i7-13700H (20 x 1826)| |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: disabled_software
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
webnn: disabled_off| |Load (avg)|2, 1, 1| |Memory (System)|15.25GB (8.08GB free)| |Process Argv|| |Screen Reader|no| |VM|0%| |DESKTOP_SESSION|gnome| |XDG_CURRENT_DESKTOP|GNOME| |XDG_SESSION_DESKTOP|gnome| |XDG_SESSION_TYPE|wayland|

Extensions (27)

Extension|Author (truncated)|Version ---|---|--- markdown-mermaid|bie|1.23.1 catppuccin-vsc|Cat|3.15.1 catppuccin-vsc-icons|Cat|1.15.0 ruff|cha|2024.42.0 vscode-markdownlint|Dav|0.55.0 EditorConfig|Edi|0.16.4 remotehub|Git|0.62.0 vscode-drawio|hed|1.6.6 mypy|mat|0.3.1 rainbow-csv|mec|3.12.0 git-graph|mhu|1.30.0 debugpy|ms-|2024.10.0 python|ms-|2024.13.2024081501 vscode-pylance|ms-|2024.8.1 jupyter|ms-|2024.7.0 jupyter-keymap|ms-|1.1.2 jupyter-renderers|ms-|1.0.19 vscode-jupyter-cell-tags|ms-|0.1.9 vscode-jupyter-slideshow|ms-|0.1.6 remote-ssh|ms-|0.113.1 remote-ssh-edit|ms-|0.86.0 azure-repos|ms-|0.38.0 remote-explorer|ms-|0.4.3 remote-repositories|ms-|0.40.0 autodocstring|njp|0.6.1 vscode-yaml|red|1.15.0 even-better-toml|tam|0.19.2

irm-codebase commented 2 months ago

Steps to reproduce:

Open VSCode in Fedora 40
Open a recent project (ec_modules, in my case)
Watch processor CPU go haywire for a while

irm-codebase commented 2 months ago

Opening through code --disable-extensions True leads to the same outcome:

bpasero commented 2 months ago

Can you follow this wiki and post the results back here to understand more about why performance is so bad for you: https://github.com/Microsoft/vscode/wiki/Performance-Issues

Thanks!

irm-codebase commented 2 months ago

@bpasero Results below

First, the issue is not an extension. Seems to be caused by fileWatcher, which after a while goes from 5% to 0% (my laptop has 20 cores, so the math adds up).

--status output:

Version:          Code 1.92.2 (fee1edb8d6d72a0ddff41e5f71a671c23ed924b9, 2024-08-14T17:29:30.058Z)
OS Version:       Linux x64 6.10.4-200.fc40.x86_64
CPUs:             13th Gen Intel(R) Core(TM) i7-13700H (20 x 400)
Memory (System):  15.25GB (9.69GB free)
Load (avg):       2, 1, 1
VM:               0%
Screen Reader:    no
Process Argv:     
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:                           disabled_software
                  vulkan:                                 disabled_off
                  webgl:                                  enabled
                  webgl2:                                 enabled
                  webgpu:                                 disabled_off
                  webnn:                                  disabled_off

CPU %   Mem MB     PID  Process
    0      203   22512  code main
    0       31   22519     zygote
    0      109   22557       gpu-process
    0       31   22520     zygote
    0        0   22522       zygote
    0      406   22579  window [1] (● landuse.ipynb - ec_modules - Visual Studio Code)
    0      141   23045         window
    0       62   22563     utility-network-service
    0      125   22737  shared-process
    0       94   22846  ptyHost
    0        0   23181       /usr/bin/bash --init-file /usr/share/code/resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
    0        0   24234         sh /usr/bin/code --status
    0       62   24239           electron-nodejs (cli.js )
    0        0   23244       /usr/bin/bash --init-file /usr/share/code/resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
    0        0   23470       /usr/bin/bash --init-file /usr/share/code/resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
    0        0   24213       /bin/bash /usr/share/code/resources/app/out/vs/base/node/cpuUsage.sh 23181
    0        0   24216         sleep 1
    0        0   24219       /bin/bash /usr/share/code/resources/app/out/vs/base/node/cpuUsage.sh 23244
    0        0   24222         sleep 1
    0        0   24290       /bin/bash /usr/share/code/resources/app/out/vs/base/node/cpuUsage.sh 23470
    0        0   24299         sleep 1
    0      234   22847  extensionHost [1]
    0        0   22915       /home/ivanruizmanuel/.vscode/extensions/ms-python.python-2024.13.2024081501-linux-x64/python-env-tools/bin/pet server
    0        0   23541       /bin/sh /home/ivanruizmanuel/.pixi/bin/ruff server
    0       16   23542         /home/ivanruizmanuel/.pixi/envs/ruff/bin/ruff server
    0       62   23548       /usr/share/code/code /usr/share/code/resources/app/extensions/json-language-features/server/dist/node/jsonServerMain --node-ipc --clientProcessId=22847
    0       62   24129       electron-nodejs (wHoOKEWNVRSM.js )
    5      125   23108  fileWatcher [1]

Workspace Stats: 
|  Window (● landuse.ipynb - ec_modules - Visual Studio Code)
|    Folder (ec_modules): more than 21411 files
|      File types: py(5118) pyc(5107) pyi(1827) h(1230) mo(713) ts(537)
|                  js(523) map(454) so(303) json(191)
|      Conf files: cmake(34) makefile(1)

bpasero commented 2 months ago

Yeah the file watcher process can produce larger loads depending on file watching needs, how fast does it recover?

irm-codebase commented 2 months ago

@bpasero I'd say several minutes, with the fans of my laptop getting quite loud haha.

I'm quite sure it's a newly introduced thing, the previous version (1.92, I think?) did not show this behaviour. Basides, the projects I'm opening are quite small, so this amount of work does not seem merited.

bpasero commented 2 months ago

Does something change when typescript.tsserver.experimental.useVsCodeWatcher is configured to false?

irm-codebase commented 2 months ago

@bpasero CPU usage is way more reasonable after setting it to false: Still some heavy work, but no core reaches 100% and there is no fan noise due to overheating.

irm-codebase commented 2 months ago

I'm not sure why an experimental feature is enabled on my build, though... I am not using the insiders version, as far as I can tell.

bpasero commented 2 months ago

@irm-codebase are you able to share the setup with me to try to reproduce? Please be specific about your setup so that I can try to replicate.

irm-codebase commented 2 months ago

Yeah, sure!

System

Hardware Information:

Hardware Model: HP HP ZBook Power 15.6 inch G10 Mobile Workstation PC
Memory: 16.0 GiB
Processor: 13th Gen Intel® Core™ i7-13700H × 20
Graphics: Intel® Graphics (RPL-P)
Graphics 1: NVIDIA RTX 3000 Ada Generation Laptop GPU
Disk Capacity: 1.0 TB

Software Information:

Firmware Version: V97 Ver. 01.03.01
OS Name: Fedora Linux 40 (Workstation Edition)
OS Build: (null)
OS Type: 64-bit
GNOME Version: 46
Windowing System: Wayland
Kernel Version: Linux 6.10.4-200.fc40.x86_64

VSCode setup

I run environments though miniforge3 (conda/mamba)
Most of my extensions are geared towards python (probably not necessary since the issue happens without them): autodocstring, cattpuccin (theme), draw.io integration, editorconfig for VS Code, Even Better TOML, Git Graph, Python extensions (Pylance, Jupyter, etc), Markdown Preview Mermaid Support, markdownlint, Mypy (the one by Matan Gover), Rainbow CSV, Ruff, Snakemake Language, YAML (by Red Hat)

global VSCode config:

{
"workbench.colorTheme": "Catppuccin Mocha",
"redhat.telemetry.enabled": false,
"[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
},
"git.autofetch": true,
"cSpell.language": "en,en-GB",    // deactivated extension
"cSpell.diagnosticLevel": "Hint",
"jupyter.runStartupCommands": [
    "%load_ext autoreload",
    "%autoreload 2"
],
"editor.fontFamily": "\"Fira Code\"",
"editor.fontWeight": "normal",
"editor.fontLigatures": true,
"workbench.iconTheme": "catppuccin-mocha",
"terminal.integrated.inheritEnv": false,
"update.mode": "manual",
"jupyter.askForKernelRestart": false,
"jupyter.notebookFileRoot": "${workspaceFolder}",
"jupyter.interactiveWindow.creationMode": "perFile",
"window.restoreWindows": "none",
"telemetry.telemetryLevel": "off",
"ruff.nativeServer": true,
"ruff.lint.ignore": [
    "PD004",
    "PD003"
],
"mypy.debugLogging": true,
"mypy.dmypyExecutable": "/home/ivanruizmanuel/miniforge3/bin/dmypy",
"typescript.tsserver.experimental.useVsCodeWatcher": false // this is what triggers the CPU insanity.
}

bpasero commented 2 months ago

I was more referring to a workspace with files where this issue reproduces. Are you using npm or pnpm?

irm-codebase commented 2 months ago

No, I am not using any of those package managers. I use miniforge and pixi for conda and pypi dependencies, depending on the project.

If you need a repo where this occurs, I'd clone this: https://github.com/calliope-project/euro-calliope-modular

I can give more specifics, if needed

bpasero commented 2 months ago

Thanks, I will try to reproduce. This setup and repo seems to me like it has nothing to do with TypeScript/JavaScript, is that true? If so, I wonder how a TypeScript related setting has an impact here...

irm-codebase commented 2 months ago

@bpasero yep, I do not do any work with those. No idea why this has any impact either. I tried some more tests with the setting deactivated. Outputs are still good enough:

bpasero commented 2 months ago

Still curious, if you run with extensions disabled for once (and the setting turned back), does it change something?

From the command line (NOT the integrated terminal in Code), execute: code --disable-extensions.

irm-codebase commented 2 months ago

@bpasero tried with code --disable-extensions on 3 different projects with "typescript.tsserver.experimental.useVsCodeWatcher": false

Seems like the typescript stuff was not the answer... two still go crazy for a bit.

https://github.com/calliope-project/ec_jrc_idees is fine
https://github.com/calliope-project/ec_modules goes nuts
https://github.com/calliope-project/euro-calliope-modular also goes nuts... but less so?

bpasero commented 2 months ago

Just to clarify, the cpu goes UP even though "typescript.tsserver.experimental.useVsCodeWatcher": false was configured?

irm-codebase commented 2 months ago

Apologies, I should've specified. Yes, CPU goes up with "typescript.tsserver.experimental.useVsCodeWatcher": false for two of these repositories.

bpasero commented 2 months ago

@irm-codebase ok that is interesting, so I feel this is actually entirely unrelated to the setting because that setting is for TypeScript projects (or JavaScript).

Are you certain the workspaces you open have no folders containing large number of files? Maybe some dot-folders that are hidden or folders with generated output?

There is a way to know exactly what is being watched after you have opened VS Code, I suggest this:

open a workspace
wait for the high CPU to have settled in the file watcher
from the command palette find "Set Log Level..."
pick "Trace"
open the output panel in the panel view
from the output drop down pick the "File Watcher"

Can you attach what it gives you? It should list all paths that are watched.

irm-codebase commented 2 months ago

@bpasero I know what it is! Your large file folder suggestion gave it away.

The culprit is snakemake. This workflow tool creates a /.snakemake folder with multiple conda environments within it. This also explains why repo 2 goes haywire: it has several "modules", each with its own set of snakemake environments. Repo 1 does not use snakemake, which explains why it has no impact.

The question is: is there a setting I can add that will tell vscode to ignore .snakemake paths? I'd like to add this to these repos as a default .vscode setting, otherwise this could brick VScode for other developers with less powerful laptops.

irm-codebase commented 2 months ago

These are all the environments created by the tool in repo 2 (it goes further down).

Being able to tell VSCode to ignore these would solve the issue.

bpasero commented 2 months ago

@irm-codebase yeah we have files.watcherExclude for that purpose.

irm-codebase commented 2 months ago

That was it! Added this configuration to .vscode/settings.json, and there is no more spike in CPU checks.

{
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/*/**": true,
        "**/.hg/store/**": true,
        "**/.snakemake/**": true
    }
}

irm-codebase commented 2 months ago

You're a real hero @bpasero!

The next thing is probably deactivating all the environment spam in the interpreter window, but that's an issue for the Python plugin.

Thank you for all the help, issue closed successfully!

microsoft / vscode

VSCode overheating a single CPU on startup in 1.92.2 #225957

System

Hardware Information:

Software Information:

VSCode setup