Repository navigation
Semantic highlighting (encodedSemanticClassifications-full) extremely slow #44851
Description
Activity
Same issue here, will try downgrading and see if that helps at all.
Please either share a project that causes this or try collecting the TS Server log:
- 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
If you can share the log, I can 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- Set
I'm sharing a log about this issue, seeing it on the last update and even without extensions enabled:
tsserver.logThere are instances of
encodedSemanticClassifications-fullon the logs it took more than 7 seconds, is that normal? I think that's the only interesting thing that I saw on this logfile:{"seq":54,"type":"request","command":"encodedSemanticClassifications-full","arguments":{"file":"/Users/negan/Projects/Firesquad/firesquad-widget/packages/widget/src/FiresquadWidget/index.tsx","start":791,"length":2560,"format":"2020"}} Perf 306 [23:37:31.425] 54::encodedSemanticClassifications-full: elapsed time (in milliseconds) 7258.0516Only followed by some open files (+2 seconds):
Open files: Info 95 [23:36:43.742] FileName: /Users/negan/Projects/Firesquad/firesquad-widget/packages/widget/src/FiresquadWidget/index.tsx ProjectRootPath: /Users/negan/Projects/Firesquad/firesquad-widget Info 95 [23:36:43.742] Projects: /Users/negan/Projects/Firesquad/firesquad-widget/packages/widget/tsconfig.json Perf 95 [23:36:43.742] 2::updateOpen: elapsed time (in milliseconds) 2642.9740Attached my log file
I also noticed with affected version that even if I manage to load the list of hints, it is not complete.
Reverting to 1.56 fixed the slowness for me too. Didn't seem to matter if I used TS 4.2 or 4.3.
Reacted by Richard Ivánek and cshaCan confirm, I also had to revert to 1.56.
Had the same problem.
I disabled TypeScript validation in Settings > Workspace > Extensions > TypeScript section..vscode/settings.json:
{ "typescript.validate.enable": false }Had the same problem.
I disabled TypeScript validation in Settings > Workspace > Extensions > TypeScript section..vscode/settings.json:
{ "typescript.validate.enable": false }how was the result after disabling the feature?
Had the same problem.
I disabled TypeScript validation in Settings > Workspace > Extensions > TypeScript section.
.vscode/settings.json:{ "typescript.validate.enable": false }how was the result after disabling the feature?
Well, I use only IntelliSense for faster coding and with this feature disabled I do not waiting for 5-15 sec to get suggestions. If I have some errors with types or any other mistakes in source code I get errors while my project recompiles.
Update: this may be related to TypeScript 4.3? After updating our codebase to TS43 VSCode's Intellisense has slowed down to a crawl even when using 1.56.2.
Reacted by Dev @ Joni.Ai and El PupiHad the same problem.
I disabled TypeScript validation in Settings > Workspace > Extensions > TypeScript section..vscode/settings.json:
{ "typescript.validate.enable": false }Update: after several days Intellisense became slow again.
54 remaining items
I'm experiencing the same issue.
Opening up Htop it seems like only 1 processor is being used to 100% while other processors are just idling.
Any ideas?
I'm on WSL2
Nick Wang (@nickwang0808) The language service is single threaded, so I would only expect to see one core used. As Andrew suggested a bug, can you please file a new issue with detailed reproduction steps, a TS Server log, and comparison with a recent version of TS that’s faster.
language service
Hmm, I'm trying to figure out a way to repro it, it has to be a fairly large repo.
Just out of curiosity, where can I find more info about TS language service being only single-threaded? I know node is a single thread but it also uses worker threads no?Reacted by JustinNick Wang (@nickwang0808) I'm not aware of a comprehensive write-up but the fundamental problem is that coordinating worker threads requires async (or an equivalent mechanism), which would spread virally through the codebase (there's no escape hatch where you can just say "wait for the async thing" and go back to being synchronous), breaking all of our public APIs. It would also require substantial re-architecture, since there's a lot of mutation (for perf reasons) that wouldn't play nicely with multiple threads.
TL;DR: We'd have to make an enormous, API-breaking code change and getting back to the current level of performance would be challenging
Nick Wang (@nickwang0808) I'm not aware of a comprehensive write-up but the fundamental problem is that coordinating worker threads requires async (or an equivalent mechanism), which would spread virally through the codebase (there's no escape hatch where you can just say "wait for the async thing" and go back to being synchronous), breaking all of our public APIs. It would also require substantial re-architecture, since there's a lot of mutation (for perf reasons) that wouldn't play nicely with multiple threads.
TL;DR: We'd have to make an enormous, API-breaking code change and getting back to the current level of performance would be challenging
OK so I just ran a test on a MacOS machine with same repo. autocomplete uses all thread, where as my machine windows-wsl2 uses only 1 thread. It was instant autocomplete on the macos where mine was around 3 sec.
https://www.reddit.com/r/vscode/comments/rgvgyc/comment/htv8dfo/?utm_source=share&utm_medium=web2x&context=3
here is another user experiencing the same issueAlso tried to install vscode directly to wsl2 and use the wsl2 gui feature, seems to be using all cores and very snappy too.
The number of threads is the same on every platform. It is, however, true that there is a helper process that will provide approximate answers until the language service is finished initializing, so it's possible that you're seeing that helper process consume a core and provide a quick answer. In some circumstances, there may also be helper processes to download type definitions automatically, but the language service proper will still use only one core.
The number of threads is the same on every platform. It is, however, true that there is a helper process that will provide approximate answers until the language service is finished initializing, so it's possible that you're seeing that helper process consume a core and provide a quick answer. In some circumstances, there may also be helper processes to download type definitions automatically, but the language service proper will still use only one core.
Here is a side by side of native windows vs WSL2
windows
https://github.com/proxy/user-images.githubusercontent.com/63834422/169404473-76d513a1-d123-4623-8885-7c434b8d4b2b.mp4
wsl2
https://github.com/proxy/user-images.githubusercontent.com/63834422/169404620-fc863967-a8c2-416c-8d54-9c750947a399.mp4the pattern is WSL2 will max out 1 CPU and everything will block, whereas windows will use all cores unless they are all maxed out it won't block
So I'm not sure where to look, can you point me to the right direction?
So I'm not sure where to look, can you point me to the right direction?
Can you elaborate? I'm not sure what you're looking for.
If your basic question is "why is the language service slower on WSL2 than on the host windows machine?", some possible causes include:
- The WSL2 VM not being able to use all cores (I'm not sure what settings control this)
- The WSL2 VM not being able to use enough memory (node/electron bogs down doing repeated GCs when it's near its limit)
- The fact that Linux doesn't support recursive file watches, so the LS has to use polling
- Accessing files across the Windows/Linux boundary (e.g. if you're binaries or sources are on your Windows file system)
It might also be worthwhile to determine which processes are using your cores on Windows because they can't all be the LS process.
Getting the same issues here. 150+ file project.
Weirdly enough its only on Windows. I have an M1 Mac which receives sub 1s Typescript results yet my Windows PC (8 core, 3GHz) takes 30 seconds for almost every change.
TSServer on both devices run at 4096mb of memory
Same here, also using
react-hook-formin a project of around 300-400 files. Super slow intellisense and compilation on WindowsReacted by P.98, Miles and ibrahim-deliceUsing combination of prisma, trpc, zod, react-hook-form. About 12 prisma models so I guess its a lot of generated code. TS version 4 and 5 destroy my CPU with constant 100% utilization. If I downgrade to TS version < 4.5 the issue goes away but I lose all the type inference (zod requires 4.5+) :/ Please fix performance issue
Edit: I think I figured out a workaround, downgrading to zod 3.19.1 and TS 4.1, seems like the issue is fixed for me
Reacted by David ReessReacted by hanayashiki and Daniel HarveyAlso experiencing these performance issues on Windows.
Wondering why this was closed without any real resolution?
Happy to run specific tests, but I am also using Prisma and Zod on a large monorepo
Tom Rowe (@TheRealFlyingCoder) (and others) If you are still seeing performance problems, please open a new issue against TypeScript with an example project which demonstrates the issue. Thanks
- locked as resolved and limited conversation to collaborators
on Jul 19, 2023
Does this issue occur when all extensions are disabled?: Yes
In 1.57.0-1623259737 version IntelliSense is terribly slow. I've no Idea, what more details should I provide. I've tested it on TypeScript/React project (also with all extensions disabled - with the same result - loading hint takes more than 10 seconds).
After downgrade to 1.56.2-1620838498 everything works great.