Unbearably slow typescript definitions

[charrondev]

Current behavior:

Some of the built-in types cause type-checking and VSCode intellisense feature to be incredibly, painfully slow.

To reproduce:

This only seems to affect large projects. For me that's working on https://github.com/vanilla/vanilla (working specifically with react components in library/src/scripts, but it reproduces in other areas as well).

I've recorded some gifs of the performance degradation.

Situation	Gif
Current Behaviour
With a slight modification of the type

Expected behavior:

Intellisense on a machine as powerful as the one I'm using should be instant. (32Gb of RAM, i9 CPU, lightning fast SSD).

Environment information:

• react version: 16.9.0
• @emotion/css version: 11.1.3

The slowness cause

Typescript has had a lot of issues recently with various libraries replicating CSS or react types. microsoft/TypeScript#34801 (comment)

In this case the cause of the slowness in particular seems to come from this piece of code

https://github.com/emotion-js/emotion/blob/master/packages/serialize/types/index.d.ts#L10-L14

export type CSSPropertiesWithMultiValues = {
  [K in keyof CSSProperties]:
    | CSSProperties[K]
    | Array<Extract<CSSProperties[K], string>> // The Extract<> here.
}

It seems the Extract<> on something with as many properties as this CSSProperties is very slow. What I've done for my own personal use was to change the code to

export type CSSPropertiesWithMultiValues = {
  [K in keyof CSSProperties]:
    | CSSProperties[K]
    | Array<CSSProperties[K]>>
}

Now this is may not be the correct type of what's allowed, as it it then allows multiple values an array of values to be passed to properties that don't support it. My question is until typescript improves the performance of Extract<> in a situation like this, what do we do?

[charrondev]

Of course immediately after filing the issue, I think I found a more correct solution.

export type CSSPropertiesWithMultiValues = {
  [K in keyof CSSProperties]:
    CSSProperties[K] extends string ? CSSProperties[K] | Array<CSSProperties[K]> : CSSProperties[K]
}

This seems to be the intention and doesn't cause the speed issues. I guess it's the Array<never> from Extract that seems to be causing the slowdown.

[charrondev]

I've opened a PR to patch the issue #2258

[jordanlatimer]

Currently experiencing this as well. Hopefully the PR works.

[amcasey]

On my box, check time for vanilla is ~22 seconds. If I rewrite ArrayCSSInterpolation, it drops to ~18 seconds.

-export interface ArrayCSSInterpolation extends Array<CSSInterpolation> {}
+export type ArrayCSSInterpolation = Array<CSSInterpolation>;

Edit: updated with numbers for a warm disk. Less impressive, but still pretty good for a one line change.

[amcasey]

@charrondev I'd be interested to know why you think Array<never> is involved. I would have guessed it was distribution over the conditional.

[Andarist]

@charrondev I'd be interested to know why you think Array is involved. I would have guessed it was distribution over the conditional.

I have a vague memory of smth like never[] causing heavy deopts that you were surprised by and you were investigating the issue. I might not remember the issue correctly though.

I would have guessed it was distribution over the conditional.

The distribution itself should be a fairly easy one here - I suspect that there are just a few items to distribute for each property. Question would be - if we have a mapped type that distributes in each of its properties then are those distributes lazily or eagerly? The object that is being mapped is a pretty big one so if the whole thing would be evaluated eagerly (OTOH I would expect the result to be cached which should make the additional autocompletes fast) then maybe this time adds up?

It would be great if there would be some kind of documentation about what happens eagerly and what happens lazily - I understand that this is often a moving target for you guys but this would help tremendously library authors.

On my box, check time for vanilla is ~22 seconds. If I rewrite ArrayCSSInterpolation, it drops to ~18 seconds.

Huh, this is a weird one - your usual recommendation is to prefer interfaces over types. What makes this case different?

[amcasey]

I have a vague memory of smth like never[] causing heavy deopts that you were surprised by and you were investigating the issue. I might not remember the issue correctly though.

Hopefully, you mean TS and not me personally, because I don't remember that investigation. 😅 Having said that, it's not obvious to me how that could cause a deopt because the code that's executing is the compiler/LS, which is not seeing never[], but rather a type representing it.

The distribution itself should be a fairly easy one here - I suspect that there are just a few items to distribute for each property.

If it adds up to hundreds of (small) subtype reductions, it can still cause a problem. That was the expensive part of #42824, for example.

Question would be - if we have a mapped type that distributes in each of its properties then are those distributes lazily or eagerly?

My guess would be lazily, but "it depends" is probably more accurate. It's a characteristic of the compiler that we're still fine-tuning (e.g. I believe things got lazier to allow recursive conditional types).

Huh, this is a weird one - your usual recommendation is to prefer interfaces over types.

I think you're referring to this pointer. I believe it was intended to refer to intersections with more than one member.

What makes this case different?

microsoft/TypeScript#42995 (comment)

[amcasey]

It's not very exciting, but I saved another half-second or so by pulling out an explicitly-typed constant for https://github.com/vanilla/vanilla/blob/7cc3ce7c31e181d934514b78c6f8406f7b5c5e3a/library/src/scripts/content/userContentStyles.ts#L720. (Otherwise, it gets checked repeatedly as part of overload resolution. Not something you should think about, in general, just a hotspot in this particular code.)

[Andarist]

Hopefully, you mean TS and not me personally, because I don't remember that investigation. 😅 Having said that, it's not obvious to me how that could cause a deopt because the code that's executing is the compiler/LS, which is not seeing never[], but rather a type representing it.

I've tried to find the issue I had a memory of... but it seems that it was just a dream... or something :P Can't find it so it probably didn't happen.

If it adds up to hundreds of (small) subtype reductions, it can still cause a problem. That was the expensive part of #42824, for example.

Wow, this is... something. Quite impressed that the OP has figured out the workaround on their own.

I think you're referring to this pointer. I believe it was intended to refer to intersections with more than one member.

Yep, was referring to this.

microsoft/TypeScript#42995 (comment)

Thanks for the pointer! It makes sense - although it's quite a hard rule to remember (it's not super intuitive).

It's not very exciting, but I saved another half-second or so by pulling out an explicitly-typed constant for https://github.com/vanilla/vanilla/blob/7cc3ce7c31e181d934514b78c6f8406f7b5c5e3a/library/src/scripts/content/userContentStyles.ts#L720. (Otherwise, it gets checked repeatedly as part of overload resolution. Not something you should think about, in general, just a hotspot in this particular code.)

What do you mean by the overload resolution here? None of the called function and the outer one has any overloads 🤔

[amcasey]

Thanks for the pointer! It makes sense - although it's quite a hard rule to remember (it's not super intuitive).

I'm still trying to figure out how best to document this. Frankly, it would never have occurred to me to subtype an array type without adding members, so it seems strange to recommend against it. I can add a footnote about array types to the intersection advice, if you think that would be helpful.

What do you mean by the overload resolution here? None of the called function and the outer one has any overloads 🤔

I was referring to the three lines above the "called function" you linked as overloads.

[charrondev]

I see you got a bit of reduction in the general type checking of the whole project, but I don't think I was negatively impacted by that time.

The negative impact is in VSCode with the language service slowing down significantly.

• Auto-imports go from taking ~300ms to 5+ seconds.
• Jump-to-definition goes from taking ~300ms to 5+ seconds.
• It can take 10+ seconds for the language service to recognize that the file was changed and clear out previous errors.

[charrondev]

Are there steps I can take to profile the language server itself? I tried logging traces in VSCode and I could definitely see the slow responses but wasn't able to really pinpoint any specific thing slowing it down. The PR I opened here was really was found by me going through commonly used types and swapping them out with any until things sped up.

If there are specific steps I can take to pinpoint them I'm open to trying them.