Unable to use TypeScript (Code Helper 100% of processor)

[davidavz]

Since a couple of days I can't use VScode properly with TypeScript (show info on hover, auto import etc.) it works 5 minutes when I launch the app and then I have a Code Helper process at 100% of processor and I can't use it anymore.
I tried reinstall 1.58.2, Insiders version but I still have this issue.

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.59 & 1.58.2
• OS Version: macOS Big Sur 11.5.1

[mjbvz]

Please follow these instructions to collect performance information. Share the output of code-insiders --status

Also, does this happen with all projects you open or just one in particular?

[davidavz]

Sorry for the double issue microsoft/vscode#130787

For the moment I just have the problem with one project, I have not tried yet with another one.

[mjbvz]

Can you share the project? If not, you can instead try collecting the TS Server log to see what is going on:

1. Set "typescript.tsserver.log": "verbose",
2. Restart VS Code and reproduce the problem
3. In VS Code, run the TypeScript: Open TS Server log command
4. This should open a large log file called tsserver.log

⚠️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

[davidavz]

It's a private project I can't share it. I have the tsserver.log but I'd rather not sharing publicly. Could I send it to you in private ?

[mjbvz]

Thanks. yes you can send it to matb at microsoft

[davidavz]

Ok I've just sent it. Thanks.

[mjbvz]

Thanks. Can you also test on the latest VS Code insiders build to confirm this hasn't already been fixed

[davidavz]

I've just tested right now and I have the same issue. I generated the tsserver.log if you want it ...

[DanielRosenwasser]

I'm not as well-versed in tsserver log reading as my coworkers, but I don't think I'm seeing anything in the logs except for the basic project loading. That does take around 6.4 seconds which isn't great, but for the number of files I'm seeing it's not out of the question. Otherwise, there's not enough context here to see what's slow, and even if we could, providing suggestions without the code in question would require a lot of time. I would suggest reading through our wiki page on Performance so that you can uncover why you might be experiencing performance issues.

Specifically, if you've avoided all the common issues, I'd suggest trying to find hot spots in a basic compilation with tsc by getting a performance trace and using @amcasey's ts-analyze-trace tool. If that doesn't point anything out that's obvious, we'd be interested in seeing the trace as well.

[jgoux]

Hello, I'm a colleague of @davidavz and I have the exact same issue since a couple of days ago.

TS server isn't outputting any error, but the logs always end up with these sequences :

Info 1417 [15:18:00.041] Starting updateGraphWorker: Project: /Users/admin/Documents/Code/Clovis-team/clovis-labs/clovis/packages/client/tsconfig.json
Info 1418 [15:18:00.100] Finishing updateGraphWorker: Project: /Users/admin/Documents/Code/Clovis-team/clovis-labs/clovis/packages/client/tsconfig.json Version: 8 structureChanged: false Elapsed: 58.97808400169015ms
Info 1419 [15:18:00.100] Different program with same set of files:: structureIsReused:: 2
Info 1420 [15:18:00.102] getCompletionData: Get current token: 0.012628000229597092
Info 1421 [15:18:00.102] getCompletionData: Is inside comment: 0.023969002068042755
Info 1422 [15:18:00.102] getCompletionData: Get previous token 1: 0.012947000563144684
Info 1423 [15:18:00.102] getCompletionData: Get previous token 2: 0.02292799949645996
Info 1424 [15:18:00.102] getCompletionsAtPosition: isCompletionListBlocker: 0.2235580012202263
Info 1425 [15:18:00.107] collectAutoImports: starting, not resolving module specifiers
Info 1426 [15:18:00.107] collectAutoImports: module specifier cache size: 7
Info 1427 [15:18:00.231] getSymbolToExportInfoMap: cache miss or empty; calculating new results
Info 1428 [15:18:00.487] getSymbolToExportInfoMap: caching results
Info 1429 [15:18:00.487] getSymbolToExportInfoMap: done in 379.4849450029433 ms
Info 1430 [15:18:00.765] collectAutoImports: done in 657.4780550003052 ms
Info 1431 [15:18:00.765] getCompletionData: Semantic work: 662.3724420033395

After these instructions, there is nothing logged until I reboot TS server (all the hover/autocomplete interactions are stuck on Loading...).

[DanielRosenwasser]

I think I see - we get a request for completions and never seem to come back with a result. I didn't catch that in the original logs. Thanks for clarifying!

My assumption is we're doing a lot of work that can't be short-circuited (most likely), or are caught in some sort of infinite loop (rarer these days).

[jgoux]

Hello, a small update!

We still aren't able to pinpoint the issue but it seems that bumping the allocated memory for tsserver "solves" the issue. ("typescript.tsserver.maxTsServerMemory": 8192), I had something like 3Go previously.

VSCode is back to normal, the autocompletion / imports and type checks are instant! 🚀

[andrewbranch]

@jgoux what version of TypeScript are you running now? Can you double check that removing that memory option actually reproduces the problem again? My understanding is that a while back, Node changed to be allowed to use however much memory the system can give it, making the --max-old-space-size flag really only able to limit the memory space, not increase it. I’m wondering if something else changed at the same time—e.g., if you’re using the nightly TypeScript builds, we’ve made some pretty major performance fixes recently (#44851) and I wonder if you’re actually seeing that instead.

[jgoux]

@andrewbranch We're using 4.4.4 right now so I don't think it's related to the last performance fixes.

If I remove the option it will fallback to its default at 3072 and the issue is back. 😅

Once the performance fixes are on stable I'll test against them with the option back to 3072 and I'll tell you if it's better. 👍

[andrewbranch]

Oh, I missed that the option has a default coming from VS Code. Very interesting. Thanks!