Semantic highlighting (`encodedSemanticClassifications-full`) extremely slow #44851

PawelJ-PL · 2021-06-11T20:30:35Z

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 · 2021-06-11T20:41:28Z

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

mjbvz · 2021-06-11T23:05:10Z

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 log command
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 · 2021-06-12T02:40:30Z

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

Negan1911 · 2021-06-12T02:49:10Z

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 · 2021-06-12T11:37:18Z

Attached my log file

tsserver.log

PawelJ-PL · 2021-06-12T13:46:56Z

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

rrdelaney · 2021-06-18T18:02:35Z

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 · 2021-06-21T14:50:02Z

Can confirm, I also had to revert to 1.56.

aarbmx6s · 2021-06-25T16:26:57Z

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

.vscode/settings.json:

{
  "typescript.validate.enable": false
}

outranker · 2021-06-28T02:44:29Z

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 · 2021-06-28T08:02:53Z

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 · 2021-06-30T17:53:33Z

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 · 2021-07-01T06:59:36Z

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 · 2021-07-01T11:08:01Z

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 [email protected] and ^[email protected].
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 ^[email protected] but was removed because lower version of ajv doesn't work with [email protected].

joniaiuser · 2021-07-04T00:01:50Z

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 · 2021-07-27T04:00:22Z

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

armanio123 · 2021-07-30T23:12:51Z

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 · 2021-07-31T02:27:17Z

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 · 2021-07-31T09:14:19Z

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

outranker · 2021-07-31T09:36:49Z

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 · 2021-07-31T09:57:15Z

It appears that ajv actually occurs as a transitive dependency:

├─┬ @typescript-eslint/[email protected]
│ └─┬ [email protected]
│   ├─┬ @eslint/[email protected]
│   │ └── [email protected] deduped
│   ├── [email protected]
│   └─┬ [email protected]
│     └── [email protected]
└─┬ [email protected]
  ├─┬ @pmmmwh/[email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   ├─┬ [email protected]
  │   │ └── [email protected] deduped
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  ├─┬ [email protected]
  │ └─┬ [email protected]
  │   └── [email protected] deduped
  └─┬ [email protected]
    ├─┬ [email protected]
    │ └── [email protected] deduped
    ├── [email protected] deduped
    └─┬ [email protected]
      └── [email protected] 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 · 2021-12-21T00:40:41Z

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

hanayashiki · 2021-12-31T09:36:02Z

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 · 2022-01-04T14:50:33Z

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 · 2022-01-04T17:00:58Z

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 · 2022-01-29T12:22:04Z

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 · 2022-02-01T11:57:50Z

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 · 2022-05-17T17:25:37Z

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 · 2022-05-19T00:25:15Z

@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 · 2022-05-19T02:25:06Z

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 · 2022-05-19T17:25:40Z

@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 · 2022-05-19T18:05:54Z

@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 · 2022-05-19T20:17:17Z

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 · 2022-05-19T21:06:51Z

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 · 2022-05-20T17:40:42Z

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 · 2022-06-23T00:44:33Z

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 · 2022-06-27T18:03:57Z

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

arnm · 2023-03-04T17:24:06Z

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 · 2023-07-19T20:16:40Z

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 · 2023-07-19T20:29:56Z

@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

vscode-triage-bot assigned mjbvz Jun 11, 2021

This comment has been minimized.

Sign in to view

mjbvz transferred this issue from microsoft/vscode Jul 1, 2021

mjbvz removed their assignment Jul 1, 2021

sandersn assigned armanio123 Jul 1, 2021

sandersn added the Needs Investigation This issue needs a team member to investigate its status. label Jul 1, 2021

sandersn added this to the TypeScript 4.4.1 (RC) milestone Jul 1, 2021

aarbmx6s mentioned this issue Jul 5, 2021

Ajv 8.6.0 makes VSCode IntelliSense extremely slow ajv-validator/ajv#1667

Closed

armanio123 mentioned this issue Aug 5, 2021

Typescript intellisense is slow #45327

Closed

ahejlsberg closed this as completed in #46429 Oct 22, 2021

ahejlsberg modified the milestones: TypeScript 4.6.0, TypeScript 4.5.1 Oct 22, 2021

Tornquist mentioned this issue Oct 27, 2021

Large schemas generate huge index.d.ts causing slow autocomplete and type-checking in your editor prisma/prisma#4807

Open

andrewbranch mentioned this issue Nov 4, 2021

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

Closed

JSin mentioned this issue Nov 8, 2021

Slow IntelliSense with react-hook-form resolvers on commands completionInfo, completionEntryDetails, and, encodedSemanticClassifications-full #46726

Open

JorgeRuizDev mentioned this issue Nov 21, 2021

Downgrade TS from 4.4.2 to 4.2.4 JorgeRuizDev/SpotMyFM#38

Closed

erikbrinkman mentioned this issue Dec 5, 2021

split union types ajv-validator/ajv#1833

Closed

gino mentioned this issue Apr 9, 2023

Very slow autocompletion performance on VSCode. colinhacks/zod#2311

Closed

This comment was marked as off-topic.

Sign in to view

microsoft locked as resolved and limited conversation to collaborators Jul 19, 2023

Semantic highlighting (encodedSemanticClassifications-full) extremely slow #44851

Semantic highlighting (encodedSemanticClassifications-full) extremely slow #44851

Comments

PawelJ-PL commented Jun 11, 2021

randomprogramming commented Jun 11, 2021

This comment has been minimized.

mjbvz commented Jun 11, 2021

Negan1911 commented Jun 12, 2021

Negan1911 commented Jun 12, 2021

PawelJ-PL commented Jun 12, 2021

PawelJ-PL commented Jun 12, 2021

rrdelaney commented Jun 18, 2021

RisaI commented Jun 21, 2021

aarbmx6s commented Jun 25, 2021

outranker commented Jun 28, 2021

aarbmx6s commented Jun 28, 2021

rrdelaney commented Jun 30, 2021

aarbmx6s commented Jul 1, 2021 • edited Loading

aarbmx6s commented Jul 1, 2021

joniaiuser commented Jul 4, 2021 • edited Loading

armanio123 commented Jul 27, 2021

armanio123 commented Jul 30, 2021

joniaiuser commented Jul 31, 2021 • edited Loading

PawelJ-PL commented Jul 31, 2021

outranker commented Jul 31, 2021

PawelJ-PL commented Jul 31, 2021

joniaiuser commented Dec 21, 2021

hanayashiki commented Dec 31, 2021

nycgavin commented Jan 4, 2022

andrewbranch commented Jan 4, 2022

DNoel26 commented Jan 29, 2022

robertwt7 commented Feb 1, 2022

nickwang0808 commented May 17, 2022

amcasey commented May 19, 2022

nickwang0808 commented May 19, 2022

amcasey commented May 19, 2022

nickwang0808 commented May 19, 2022 • edited Loading

amcasey commented May 19, 2022

nickwang0808 commented May 19, 2022 • edited Loading

amcasey commented May 20, 2022

sannajammeh commented Jun 23, 2022 • edited Loading

wowczarczyk commented Jun 27, 2022

arnm commented Mar 4, 2023 • edited Loading

TheRealFlyingCoder commented Jul 19, 2023

This comment was marked as off-topic.

mjbvz commented Jul 19, 2023

Semantic highlighting (`encodedSemanticClassifications-full`) extremely slow #44851

Semantic highlighting (`encodedSemanticClassifications-full`) extremely slow #44851

aarbmx6s commented Jul 1, 2021 •

edited

Loading

joniaiuser commented Jul 4, 2021 •

edited

Loading

joniaiuser commented Jul 31, 2021 •

edited

Loading

nickwang0808 commented May 19, 2022 •

edited

Loading

nickwang0808 commented May 19, 2022 •

edited

Loading

sannajammeh commented Jun 23, 2022 •

edited

Loading

arnm commented Mar 4, 2023 •

edited

Loading