Semantic highlighting (encodedSemanticClassifications-full) extremely slow

[PawelJ-PL]

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

• VS Code Version: 1.57.0-1623259737
• OS Version: Debian GNU/Linux 11 (bullseye)

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.

[randomprogramming]

Same issue here, will try downgrading and see if that helps at all.

[mjbvz]

Please either share a project that causes this or try collecting the TS Server log:

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

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

[Negan1911]

I'm sharing a log about this issue, seeing it on the last update and even without extensions enabled:
tsserver.log

[Negan1911]

There are instances of encodedSemanticClassifications-full on 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.0516

Only 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.9740

[PawelJ-PL]

Attached my log file

tsserver.log

[PawelJ-PL]

I also noticed with affected version that even if I manage to load the list of hints, it is not complete.

[rrdelaney]

Reverting to 1.56 fixed the slowness for me too. Didn't seem to matter if I used TS 4.2 or 4.3.

[RisaI]

Can confirm, I also had to revert to 1.56.

[aarbmx6s]

Had the same problem.
I disabled TypeScript validation in Settings > Workspace > Extensions > TypeScript section.

.vscode/settings.json:

{
  "typescript.validate.enable": false
}

[outranker]

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?

[aarbmx6s]

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.

[rrdelaney]

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.

[aarbmx6s]

Had 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.

[aarbmx6s]

After investigation I found an issue related to my project. I don't know will it works for others.
I was removing and installing packages which I use in my project and discovered the next issue related to eslint and ajv packages.
My project has used eslint@7.25.0 and ^ajv@8.1.0.
After upgrading eslint to 7.29.0 version and downgrading ajv to 7.2.4 version the IntelliSense starts work extremely faster, sometimes it takes a little time to get list of suggestions.
After completely removing ajv from project IntelliSense work perfect without any delay.
Now in my project uses older version of ajv.
Also project has used ^ajv-formats@2.1.0 but was removed because lower version of ajv doesn't work with ajv-formats@2.1.0.

[joniaiuser]

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.

I have this same issue on 1.57 and 1.58 (Insider) VSC, noticed Intellisense in VS code slowing down significantly. Downgrading to Typescript 4.2 seems to speed things up by a factor of 10.

Server log attached.

tsserver.log

[armanio123]

The slowness is caused by PR #30639. I'm still looking at options on how to avoid this.

[armanio123]

Alright I've been looking into it and seems like it's going to be complicated to optimize. All the problem is that typescript is doing a bit more work to relate conditional types (in this example the problem is with type UncheckedJSONSchemaType on file node_modules/ajv/dist/types/json-schema.d.ts)

Nevertheless, we can still get into a good performance by dividing the type into sub named types. I've done some tests and manage to get encodedSemanticClassifications-full to about a second just by doing that.

Check the gist with how the file look after testing: https://gist.github.com/armanio123/95a33f9ad3286a7d78590eb11af293c4

I don't know much about the project, so all my types on the example are named just an alphabet letter.

[joniaiuser]

I'm not using Ajv in my system though. If it's a widespread issue, should it be highlighted as a breaking change so that library maintainers can update their types accordingly?

Barring that, the PR should be reverted?

[PawelJ-PL]

I have reported this issue, but I also do not use ajv

[outranker]

I have reported this issue, but I also do not use ajv

Is it possible a package in your project has ajv as a dependency? Coule you please confirm by looking at package-lock.json or yarn.lock?

[PawelJ-PL]

It appears that ajv actually occurs as a transitive dependency:

├─┬ @typescript-eslint/parser@4.26.1
│ └─┬ eslint@7.28.0
│   ├─┬ @eslint/eslintrc@0.4.2
│   │ └── ajv@6.12.6 deduped
│   ├── ajv@6.12.6
│   └─┬ table@6.7.1
│     └── ajv@8.6.0
└─┬ react-scripts@4.0.3
  ├─┬ @pmmmwh/react-refresh-webpack-plugin@0.4.3
  │ └─┬ schema-utils@2.7.1
  │   └── ajv@6.12.6 deduped
  ├─┬ eslint-webpack-plugin@2.5.4
  │ └─┬ schema-utils@3.0.0
  │   └── ajv@6.12.6 deduped
  ├─┬ file-loader@6.1.1
  │ └─┬ schema-utils@3.0.0
  │   └── ajv@6.12.6 deduped
  ├─┬ mini-css-extract-plugin@0.11.3
  │ └─┬ schema-utils@1.0.0
  │   ├─┬ ajv-errors@1.0.1
  │   │ └── ajv@6.12.6 deduped
  │   └── ajv@6.12.6 deduped
  ├─┬ postcss-loader@3.0.0
  │ └─┬ schema-utils@1.0.0
  │   └── ajv@6.12.6 deduped
  ├─┬ sass-loader@10.2.0
  │ └─┬ schema-utils@3.0.0
  │   └── ajv@6.12.6 deduped
  ├─┬ terser-webpack-plugin@4.2.3
  │ └─┬ schema-utils@3.0.0
  │   └── ajv@6.12.6 deduped
  ├─┬ url-loader@4.1.1
  │ └─┬ schema-utils@3.0.0
  │   └── ajv@6.12.6 deduped
  ├─┬ webpack-dev-server@3.11.1
  │ └─┬ schema-utils@1.0.0
  │   └── ajv@6.12.6 deduped
  └─┬ webpack@4.44.2
    ├─┬ ajv-keywords@3.5.2
    │ └── ajv@6.12.6 deduped
    ├── ajv@6.12.6 deduped
    └─┬ schema-utils@1.0.0
      └── ajv@6.12.6 deduped

I suspect then that here eslint may be the prime suspect. However, as far as I understand, I can fix in my code.

[joniaiuser]

Why is this closed? It's not fixed even in latest version. I still see significant performance regression.

[hanayashiki]

TypeScript: 4.5.4

It takes about 6-7 seconds after my identifier is correctly marked not found and another 6-7 seconds to erase the red line after I correct it.

https://youtube.com/shorts/dLvwjE8zEe8?feature=share

This is a moderately sized project (50000 lines) with 20-30 imports and the file is around 200 lines.

[nycgavin]

I'm using react-hook-form as well, and I'm also having this issue, upgrading to typescript 4.5 doesn't fix the issue

[andrewbranch]

Please file a new issue with detailed reproduction steps, a TS Server log, and comparison with a recent version of TS that’s faster.

[DNoel26]

May help someone. Added the below to my package.json

"scripts": {
        ......
        "typecheck": "tsc",
        "typecheck:watch": "tsc -w"
    },

and included the below in my settings.json

"javascript.validate.enable": false,
"typescript.validate.enable": false,

I use watch in a split terminal for type checking while I code. A bit less convenient but it's basically instant now vs 10-30+ seconds for something such as renaming a symbol or importing

[robertwt7]

Hey team,

I'm also experiencing this in the latest one. I'm not sure why it's closed? Doesn't happen on my mac though. It only happens on my PC (windows).

When i press save, it takes 4-5s for typescript to update the errors in my vscode

[nickwang0808]

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

[amcasey]

@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.

[nickwang0808]

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?

[amcasey]

@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

[nickwang0808]

@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 issue

Also tried to install vscode directly to wsl2 and use the wsl2 gui feature, seems to be using all cores and very snappy too.

[amcasey]

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.

[nickwang0808]

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://user-images.githubusercontent.com/63834422/169404473-76d513a1-d123-4623-8885-7c434b8d4b2b.mp4
wsl2
https://user-images.githubusercontent.com/63834422/169404620-fc863967-a8c2-416c-8d54-9c750947a399.mp4

the 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?

[amcasey]

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.

[sannajammeh]

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

[wowczarczyk]

Same here, also using react-hook-form in a project of around 300-400 files. Super slow intellisense and compilation on Windows

[arnm]

Using 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

[TheRealFlyingCoder]

Also 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

[mjbvz]

@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