Major CPU Usage with v1.74-on #52535
Comments
|
It's been 3 weeks and nobody has bothered to check to see what could be causing this problem? |
|
Ok, I can add additional context. I have gone ahead and disabled ALL my extensions, including even uninstalling those that are deprecated (though I think disabling should have been enough). I even ran the Start Extension Bisect command, to which I continue to see that VSC CPU usage averages between 8% and 12%. And this is using VSC v1.74.3. The command indicated it may be a problem with Code. I also opened up the process explorer to see what could be causing a problem. The only line that indicated an increase in CPU usage was something from extensionHost: "C:\Program Files\Microsoft VS Code\Code.exe" --ms-enable-electron-run-as-node --max-old-space-size=3072 "c:\Program Files\Microsoft VS Code\resources\app\extensions\node_modules\typescript\lib\tsserver.js" --useInferredProjectPerProjectRoot --enableTelemetry --cancellationPipeName C:\Users{MYUSERNAME}\AppData\Local\Temp\vscode-typescript\5f167de2a50f10f9d5a4\tscancellation-af47bae0b13580d1b87e.tmp* --locale en --noGetErrOnBackgroundUpdate --validateDefaultNpmLocation --useNodeIpc Any help will be greatly appreciated since this is really cutting into our development time. |
|
Does this reproduce in the latest VS Code insiders build with all extensions disabled? |
|
Insiders build? What exactly is the Insiders Build? I have only used the regular VSCodeUSerSetup installer, the latest of which is 1.74.3. The latest insiders build that for yet-to-be released versions? |
|
The link tells you this: https://code.visualstudio.com/insiders/ |
|
Ok, I just tried it, and since I have never used this, I have no extensions installed for it. However, it's still doing the CPU issue: One key way of testing - I go into my Angular component file, and I ctrl+click on a model or service method I want to be redirected to. With the Insider version, it takes roughly 3 seconds to be redirected to the model or service I want to investigate. With VSC v.1.73.1, the redirection is almost instantaneous. |
|
Thanks for testing. Can you please share a minimal example angular project which demonstrates this issue |
|
It's hard to share such a project with what I am allowed to share. Here is a test one: I just tested it out. In VSC v1.73.1, when I ctrl+click the model, it appears instantenously, even when I don't have the file opened. With the Insider version, it takes between 2 and 3 seconds for it to load and appear in the code. |
|
Thanks. Where exactly are you ctrl clicking in that project that appears slow? |
|
On FirmSummaryViewModel. ctrl+click on FirmSummaryViewModel. |
|
Hm, doesn't repo for me:
Can you try to the TS Server log from when the happens:
That file includes timing information about how long various operations take. They should help us understand what is being slow
|
|
tsserver.log |
|
Ok, I did my own diagnostic of the issue and I might be able to shed a little light. I can't indicate the file paths involved, but I can indicate the file names and the models I'm trying to use in my main project. So, I tried to time my ctrl+click and model load, and I was able (with my human eye) to click on the model around the :00 second span, and to my knowledge, it loaded the file and the class I was looking for in :04.5 seconds. In the tsserver.log file, I came across these key items in the log: I see this next: Followed by: This file in this response is where the model class I was looking for but again I didn't see it get loaded. I also saw quite a bit of Scheduled: {root}/tsconfig.jsonFailedLookupInvalidation calls that were being scheduled and cancelled. The log continues... At this point, remember I said I noticed the file get opened at roughly :04.5 seconds, so this marker in the log would be an appropriate spot to indicate when I finally saw the file and class opened up in the editor. Like you can see here, it took nearly 4 seconds for me just to click and see the file. Any further ideas? |
|
Ok, this is getting interesting. So I managed to reinstall version 1.73.1 and load VSCode. I went to the same file, with the same model I want to see and ctrl+clicked to the same model I wanted to see. It was instantenous. I found the following in the tsserver.log, in fact no need to partition out what I see in the server log, I'll paste it in its entirety (minus the root paths): (Side Note: I think it is around this point where I would see the file loaded and the class I ctrl+clicked) I noticed a lot of updateGraphWorker calls NOT being made, and also quickInfo was not being used. I hope this helps us come to a conclusion as to why it's taking so much longer with the same project but in a different, newer version of vscode. |
|
Thank you for the investigation @tgfactor! This is very helpful I've moved this issue over to the TypeScript team who may have a better understanding of what is going wrong here |
RyanCavanaugh
added
the
Needs Investigation
|
Edited your comments as I was having trouble reading the traces. |
|
It's been a couple of weeks and I wanted to see if anything new has come up to explain why this would be happening. |
|
I've been unable to reproduce this; navigating to The tsserver log uploaded isn't the one you did your analysis on, and in the log I don't see a But, I do see in the logs a near constant stream of Can you try setting: In your VS Code settings? This default was recently changed to a new watching method, and the above would restore an older version. If this is easily reproducible for you, I would also consider downgrading TS and setting VS Code to use it, just so you can go back and find the TS version where this changed. The VS Code version is not super helpful in that way, though it's probable that it's TS 4.9 given v1.74 introduced it. |
|
We faced a similar thing, it was resolved by selecting the lower typescript version from node_modules (hover |
|
It's good to know that downgrading fixes it as it means that something changed, but I would really appreciate it if you could try the suggestion above and see if playing with the watch mode changes anything for you in TS 4.9. (We want to fix the problem, not tell everyone to downgrade!) |
|
@jakebailey Yes it fixed performance as well |
|
@sheetalkamat for interest. |
|
Can you tell me about where your project lives on disk? Is it somewhere that's synced to OneDrive, for example? |
|
The test project I submitted here, or the actual project where I first encountered this issue? |
|
The latter, though if the test project you linked isn't representative of the actual project and doesn't reproduce the issue, then I'm not sure what to do with it. So, either, so long as something is showing the high CPU usage + FileWatcher events? @Lonli-Lokli already tried the file watching change, but I'd appreciate it if you tried it as well. |
|
Yeah, I can't disclose the other project, as it is company code. However, I did have one of my developers try out the watchOptions solution, and he told me it was a lot faster for him accessing files with ctrl + clicks. My hope is not to downgrade TS especially since we are getting ready to upgrade to Angular 15. But for right now, we'll continue to give this a shot and see how it works out. |
|
Not disclosing it is fine, though it is possible for us to view the code under NDA (not uncommon given how much closed-source TS there is out there). I am still interested in what the environment is that you're running under; is it always Windows? Where are the files saved? For example, my Documents dir is synced to OneDrive, and that can have a performance impact. Does your sample repo produce the same thing? |
|
Always Windows. Unfortunately, I can't give an accurate account now, since I just upgraded my machine to Windows 11. |
|
I talked to one of my other developers having the same issue on an older machine, told him to add the watchOptions property to his VSC, and he said it was running a lot faster than before. |
|
Thanks for the info; I'm still looking for more info about the systems themselves, specifically where the files are stored. Is this in a drive which is networked? Shared on OneDrive? Is Defender active? Some other corporate software that may be touching the files? |
|
The files are stored locally. They are not involved with onedrive or any other networked drive. We do have Windows Security active and use FortiClient. |
|
Is there any new update on this issue? One of my other developers just upgraded to v1.76.1, and he tells me that the long wait times between ctrl+click on classes is still happening. |
I'm running into a similar problem on a workspace with a vue 2 frontend, a hapi backend, and a common folder all of which are in JS. I'm getting 10s of thousands of those lines. The log I've attached is from ~2 minutes of activity. Over the course of <24hrs that I had verbose logging turned on, I have over 1GB of log files. And half that time, the computer should've been asleep. I'm using VSCode's built-in TS version since it's a JS project. System Info
I also can't send you the codebase, but if it helps at all, here's the jsconfig data: service jsconfig.json{
"compilerOptions": {
"target": "ES2021",
"module": "Node16",
"lib": ["es2022"],
"baseUrl": ".",
"moduleResolution": "nodenext",
"paths": {
"#cache/*": ["./src/cache/*"],
"#routes/*": ["./src/routes/*"],
"#helpers/*": ["./src/helpers/*"],
"#types/*": ["./src/types/*"],
"#src/*": ["./src/*"]
},
"types": ["./src/types/environment", "node"],
"strict": true
},
"include": ["src"],
"exclude": ["node_modules"]
}client jsconfig.json{
"compilerOptions": {
"lib": ["DOM", "es2022"],
"types": ["vite/client", "./src/types/environment"],
"baseUrl": ".",
"moduleResolution": "NodeNext",
"paths": {
"@/*": ["src/*"]
},
"jsx": "preserve"
},
"vueCompilerOptions": {
"target": 2.7
}
}common jsconfig.json{
"compilerOptions": {
"target": "ES2021",
"module": "Node16",
"lib": ["es2021"],
"baseUrl": ".",
"moduleResolution": "nodenext",
"paths": {
"arcade-common/types": ["./src/types.js"]
},
// "types": ["./src/types/environment", "node"],
"strict": true
},
"include": ["src"],
"exclude": ["node_modules"]
} |
|
No update besides that #52876 is pretty sure the same thing. TS 4.9 changed the watch default to use native watching more, and that apparently was not good, so I can only suggest changing your watch setting back to a polling-based one if it's not working correctly. |
|
FYI, as of now (and I'm assuming it's due to a very recent Windows Update) I'm no longer able to "run and debug" with VSCode on my Angular project while still running v1.73.1. In order for me to effectively debug my application, I have to upgrade to v1.76.x. In addition, the solutions provided here may have once temporarily solved this issue, but now according to other developers, they no longer apply, or do not solve it like it used to be in 1.73. |
|
Nothing would have changed about watching in 1.76.x; is what you have been setting what I suggested to add to your VS Code user config? |
|
Correct. My other developer confirmed that even with that setting turned on, it still takes him about 10s to go to the definition via ctrl+click if it isn't already cached. |
|
After updating past 1.74 I was seeing 5-7% cpu usage for tsserver, or about a full proccessor (14 cores, 20 logical processors), after applying switching to |
Type: Bug
Ever since I installed version 1.74.x, I have run into a major CPU usage issue, especially if I work on any Angular scripts. As of right now, sitting idle, I look at my task manager and see my CPU usage is averaging around 18% for VSC alone. And that is with all the included extensions listed below. If I install version 1.73, with the same exact extensions listed below, my CPU usage in idle mode drops to barely 1% maybe 2%. My initial thought was the angular language service was causing the slowdown, but I need that extension to properly do my Angular coding. Any idea what the issue could be?
VS Code version: Code 1.74.2 (e8a3071ea4344d9d48ef8a4df2c097372b0c5161, 2022-12-20T10:29:14.590Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No
System Info
canvas_oop_rasterization: disabled_off
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_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
Extensions (27)
A/B Experiments
The text was updated successfully, but these errors were encountered: