TypeScript
TypeScript copied to clipboard
microsoft
TS Perf degradation since last version upgrade
Type: Bug
Working on TS files, performace has degraded drastically since the last version upgrade (I have auto update on). Intellisense is stuck, saving takes more than 30s (format on save is on), seems to be stuck on "Organize imports".
VS Code version: Code 1.98.0 (Universal) (6609ac3d66f4eade5cf376d1cb76f13985724bcb, 2025-03-04T21:06:18.612Z) OS version: Darwin arm64 24.3.0 Modes:
System Info
| Item | Value |
|---|---|
| CPUs | Apple M2 Max (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 webnn: disabled_off |
| Load (avg) | 10, 15, 8 |
| Memory (System) | 32.00GB (14.16GB free) |
| Process Argv | --crash-reporter-id 0b94ffbf-7f47-46d4-ba50-f0cce0fcd724 |
| Screen Reader | no |
| VM | 0% |
Extensions (20)
| Extension | Author (truncated) | Version |
|---|---|---|
| gitlens | eam | 16.3.2 |
| EditorConfig | Edi | 0.17.1 |
| prettier-vscode | esb | 11.0.0 |
| codespaces | Git | 1.17.3 |
| copilot | Git | 1.277.0 |
| copilot-chat | Git | 0.25.0 |
| vscode-github-actions | git | 0.27.1 |
| vscode-pull-request-github | Git | 0.106.0 |
| vscode-docker | ms- | 1.29.4 |
| playwright | ms- | 1.1.13 |
| debugpy | ms- | 2025.4.0 |
| python | ms- | 2025.2.0 |
| vscode-pylance | ms- | 2025.3.1 |
| remote-containers | ms- | 0.401.0 |
| cmake-tools | ms- | 1.20.53 |
| cpptools | ms- | 1.24.2 |
| cpptools-extension-pack | ms- | 1.3.1 |
| svg-preview | Sim | 2.8.3 |
| code-spell-checker | str | 4.0.40 |
| cmake | twx | 0.0.17 |
(1 theme extensions excluded)
A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt551cf:31249601
vscod805cf:30301675
binariesv615:30325510
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
2e7ec940:31000449
pythontbext0:30879054
cppperfnew:31000557
dwnewjupyter:31046869
nativerepl2:31139839
pythonrstrctxt:31112756
nativeloc1:31192215
iacca1:31171482
5fd0e150:31155592
dwcopilot:31170013
6074i472:31201624
dwoutputs:31242946
customenabled:31248079
9064b325:31222308
copilot_t_ci:31222730
f5992895:31254866
jda6j935:31233686
See also https://github.com/microsoft/vscode/issues/24307
Here on Darwin, there on Windows, but it would be better to have only one issue about this topic.
Any chance to try
F1 / Help: Start Extension Bisect?
Ran it and managed to reproduce, seems to be caused by typescript since running a compile script throws OOM
tsc dump
<--- Last few GCs --->
[3886:0x150008000] 28240 ms: Mark-Compact 4038.7 (4135.3) -> 4027.1 (4140.3) MB, 529.58 / 0.00 ms (average mu = 0.739, current mu = 0.171) allocation failure; scavenge might not succeed
[3886:0x150008000] 29342 ms: Mark-Compact 4043.0 (4140.3) -> 4033.4 (4146.1) MB, 1086.46 / 0.00 ms (average mu = 0.444, current mu = 0.015) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0x10485553c node::Abort() [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
2: 0x10485573c node::ModifyCodeGenerationFromStrings(v8::Local<v8::Context>, v8::Local<v8::Value>, bool) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
3: 0x1049da6c4 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
4: 0x104baedb8 v8::internal::Heap::GarbageCollectionReasonToString(v8::internal::GarbageCollectionReason) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
5: 0x104bad894 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
6: 0x104ba40ac v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
7: 0x104ba490c v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
8: 0x104b8997c v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
9: 0x104f71444 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
10: 0x1052d0c44 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
11: 0x1052d13fc Builtins_StringAdd_CheckNone [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
12: 0x10530f37c Builtins_StringAddConvertRight [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
13: 0x10bc337f4
14: 0x10b9a4ce0
15: 0x10bc3471c
16: 0x10bc34adc
17: 0x10bcdf2f8
18: 0x10bb65d48
19: 0x10b9dfd78
20: 0x10b876854
21: 0x10b9f540c
22: 0x10ae65b8c
23: 0x10bb1b960
24: 0x10ab30f74
25: 0x10ab327b0
26: 0x10b875df0
27: 0x10b9f540c
28: 0x10ae65b8c
29: 0x10ac8d5d4
30: 0x10ab30ebc
31: 0x10ab327b0
32: 0x10b875df0
33: 0x10b9f540c
34: 0x10ae65b8c
35: 0x10bb3439c
36: 0x105248f80 Builtins_InterpreterEnterAtNextBytecode [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
37: 0x10ab327b0
38: 0x10b875df0
39: 0x10b9f540c
40: 0x10ae65b8c
41: 0x10b8761c8
42: 0x10b9f540c
43: 0x10ae65b8c
44: 0x10b8761c8
45: 0x10b9f540c
46: 0x10ae65b8c
47: 0x10aaf01e0
48: 0x10b8d1a40
49: 0x10be63dc0
50: 0x10b929fe0
51: 0x10b8273c0
52: 0x10b927808
53: 0x10ae63040
54: 0x10ae268d8
55: 0x10bc614f4
56: 0x10ba48424
57: 0x10bd1ec4c
58: 0x10bd1e944
59: 0x10bc1b420
60: 0x10ae269c4
61: 0x10b825470
62: 0x10b934c74
63: 0x10b993d70
64: 0x10ba68e84
65: 0x10bc26b90
66: 0x10b81e4f8
67: 0x10b9ca1c4
68: 0x10b92a5fc
69: 0x10b95952c
70: 0x10b92a368
71: 0x10be64d44
72: 0x10b856b6c
73: 0x10be15a94
74: 0x10af50ed4
75: 0x10ba67068
76: 0x10aca14c8
77: 0x10bbaf774
78: 0x10ab1428c
79: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
80: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
81: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
82: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
83: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
84: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
85: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
86: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
87: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
88: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
89: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
90: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
91: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
92: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
93: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
94: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
95: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
96: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
97: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
98: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
99: 0x1052483e4 Builtins_InterpreterEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
100: 0x10524650c Builtins_JSEntryTrampoline [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
101: 0x1052461f4 Builtins_JSEntry [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
102: 0x104b1c260 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
103: 0x104b1b6ac v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
104: 0x1049f5f7c v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
105: 0x1048384d0 node::builtins::BuiltinLoader::CompileAndCall(v8::Local<v8::Context>, char const*, node::Realm*) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
106: 0x1048c5f9c node::Realm::ExecuteBootstrapper(char const*) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
107: 0x10481ccb8 node::StartExecution(node::Environment*, std::__1::function<v8::MaybeLocal<v8::Value> (node::StartExecutionCallbackInfo const&)>) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
108: 0x1047894a8 node::LoadEnvironment(node::Environment*, std::__1::function<v8::MaybeLocal<v8::Value> (node::StartExecutionCallbackInfo const&)>) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
109: 0x104895b4c node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
110: 0x104895928 node::NodeMainInstance::Run() [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
111: 0x10481f6b8 node::Start(int, char**) [/Users/shaman123/.nvm/versions/node/v20.11.0/bin/node]
112: 0x19c9d8274 start [/usr/lib/dyld]
zsh: abort npx tsc > dump.txt
See also #24307
Here on Darwin, there on Windows, but it would be better to have only one issue about this topic.
not related AFAIK
I can reproduce Organize Imports is causes a lot of problems but not only. I disabled it, it improved perf a bit, but still intellisense is extremely slow. I expect it to be exponentially faster than I am, that is how it worked before the upgrade. Now I am writing code faster than waiting for a paste action of 3 words to complete. VSCode is great, I hope you find out the cause soon. Thanks.
This video shows working on the insiders edition.
https://github.com/user-attachments/assets/740d8e59-c64d-44c8-a913-9d41327f8867
Thanks for checking. Can you please try collecting the TS Server log so we can investigate:
- Set
"typescript.tsserver.log": "verbose", - Restart VS Code and reproduce the problem
- In VS Code, run the
TypeScript: Open TS Server logcommand - This should open a large log file called
tsserver.log
Look through that log file for errors or stack traces. If you can share the log, I can also take a look to see if anything stands out
⚠️Warning: The TypeScript log may include information from your workspace, including file paths and source code. If you have any concerns about posting this publicly on Github, just let me know and we can arrange something else. On our side, we only use these logs to investigate issues like this
Thanks for the warning. Since I am under an NDA l prefer to send it to you directly (though it seems harmless), then it is fine for you guys to use it for investigations. I have reproduced it both on the insiders version and on the official version. I have observed that when I started to work on insiders the problem wasn't as bad (I shut down my computer during night). As I continued investigating, it deteriorated dramatically whereas on the official version it was deteriorated to begin with. I have tried toggling the organize import setting. When I disabled it everything still lagged but the organize import status notification didn't appear at the bottom right corner and imports were indeed not reordered. I have also tried changing the TS version. That didn't make any difference. I've created 5 log files covering these cases. In the logs I can see diagnostics for organize imports and for other autocompletion suggestions. I don't know what the values mean but in reality it takes 10-30s+ for suggestions to show.
Regardless I have tried to reproduce on another project which is open source. The project is small in file/code/dependency size. I can't reproduce the problem there, see the log file:
tsserver small open source project.log
For ease of triaging I want to stress that I am not sure vscode is to blame. As mentioned when I compile the project it dies due to OOM.
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
Process explorer, just in case it helps
https://github.com/user-attachments/assets/0d69b562-0ff2-4b57-8a0b-1cc18dec6658
Apparently the project reached the 4GB TS server limit. I've doubled it to 8GB and now everything has returned to work as expected. I suggest adding a warning when this happens so it is visible to the dev.
Is this a bug consuming resources or did I really reach 4GB of memory usage? Is that possible for a large project?
I forked a large TS project and added some types, mainly remapping of large maps using the following, where keyof T is an enum:
type ExpandedMap<T> = { [K in keyof T]: { key: K, data: T[K] } }
It caused TS to crash with OOM. During my triage attempts I emptied the map types I was working on and that made everything work as before:
type ExpandedMap<T> = { [K in keyof T]: { key: K, data: T[K] } };
type Nil = {};
ExpandedMap<Nil>;
EDITED: Tried it now and got an OOM
I raised the limit massively and now windows crashes multiple applications with an out of virtual memory error (100gb) after vscode is open a few days !
We need something we can clone and run locally in order to investigate
I am not sure I managed to repro something that will help but I tried https://github.com/ShaMan123/TS_PERF_REPRO
I'm seeing ~80 MB usage (i.e. normal) in both tsc and tsserver in that repo