TypeScript: ~50x regression in type instantiation count between 3.3 and 3.4

So, the change that introduced the perf issue is a change that caused us to instantiate the trueType of a conditional a bit more eagerly (previously in that example we wouldn’t have bothered, unlike in many others). This in and of itself shouldn’t be an issue - the instantiation should not be anywhere near this expensive (and it is cached, so the effect on a single-usage example like this is outsized). All that’d be needed was a slightly different argument type before and we’d have been off to the races all the same. So the question that leads to is this: “Why is that instantiation expensive?”.

From the declaration side, it’s obvious that the instantiation becomes expensive because JSX.IntrinsicElements has a lot of members and each of those members have a lot of props - cutting down on these or avoiding mentioning them in the types helps. While true, this observation isn’t useful - we want to be able to represent all these components and props.

From the implementation side, these types are expensive because of how we handle distribution. We have this thing called a “distributive constraint” - there’s a number of issues open W.R.T. it’s unsoundness, but on top of that, the distributive constraint works as a constraint-based work multiplier. Rather than lazily deferring work, the distributive constraint eagerly partially evaluates conditionals in an attempt to “narrow” them while looking at constraints. It does this very inefficiently - every instantiation has to go back to the root conditional and re-instantiate and re-narrow; there is no “progressive instantiation” as most other types (ie, indexed accesses) have (instead the mapper is used as a transform which we we apply over and over onto a different base checkType). This process ends up being hideously expensive for distributions over large unions (as we repeat large chunks of the instantiation work up to that point for every union member). Similarly, within getLowerBoundOfKeyType we have getLowerBoundOfConditionalType which has the same problem - it takes the check type to its constraint and reevaluates the conditional, causing a bunch of work to be kicked off (this becomes the biggest issue once you remove the distributive constraint from the picture).

In short, the pattern we have of using a conditional type’s root and re-instantiating part of the root with the current mapper (potentially after layering on another mapper to map to a specific union member of constraint) is an exponential factory of work. In every case, we make a new mapper for the specific checkType, combine it with the existing non-distributive mapper, and create an instantiation. This new mapper 1. Still repeats all the old mapper’s work, since it’s starting from the conditional’s root, and 2. re-does this work for every member we create a new mapper for. And in doing so, we manufacture new type identities for any types not cached on structure, eg objects and (prior to their fix), substitutions, none of the work for which can be pulled from any caches.

If we could find a way to safely reduce or remove usages of getConstraintOfDistributiveConditionalType and getLowerBoundOfConditionalType, combined with correct substitution type caching, we can reclaim 80% of the additional time spent by 3.4 on the original example (ie, 3.4s on my machine down to 0.7s on release-3.4 by replacing or removing those.). The key bit here is removing this work safely - we added all of these changes to fix a number of bugs and regressions and despite their flaws, they are useful.

So, this leads me to question our current construction of distributive conditionals and its inefficiency: Why are they as they are? Simply because the current formulation makes is easy to track substitutions as they occur - we don’t need to worry about remapping any instantiables within the branches. However this seems unfortunate - we’d really like to be able to say, when T extends U ? T : never becomes A | B extends U, that we can immediately distribute. The reason we don’t is because we’ve not made explicit what a distribution is: A distribution operation is the creation of a new type parameter (similar to an existential) extending the original. We avoid actually making this, but the method of construction (finding the root type parameter and pre-mapping it) should make this obvious. If we explicitly do this, we can read T extends U ? T : never as T extends U ? (T' extends T) : never, which upon instantiation can become (T' extends A | B) extends U ? (T'' extends T' extends A | B) : never which then when we’re going to the constraint (or instantiated with the constraint), allows us to make A extends U ? (A' extends A) : never | B extends U ? (B' extends B) : never via union of multiple instantiations. A and B themselves can still be type parameters to which this process can continue occurring, allowing us to repeatedly instantiate without needing to reapply from the root. I think that’d save some work, but not all of it - outright avoiding checking a “distributive constraint” at all would be better (which, IMO, we should be able to have - the apparent type of T extends string ? T : undefined is T & string and we can use that correctly, distributive or not, the issue is when T extends string ? never : T - we should have T & not string which we can’t currently represent and use the distributive constraint as a standin for!).

The notes from @RyanCavanaugh seem to imply that the fix in DT on @types/styled-components at 4.1.14 is a viable solution for the performance regression against 3.4, but I’m not seeing similar speedup in a real-world project.

Using the latest @types/styled-components at 4.1.14, I still see about 2x slower compile times on TypeScript 3.4.3 versus 3.3.4000

Aside from raw tsc compile times, when using TypeScript 3.4.3 the VSCode code helper is still racing at 100% CPU and error information feedback is painfully slow to update.

Comparatively, the VSCode integration is workable with 3.3.4000, but not what it used to be…

When testing with TypeScript 3.5.0-dev.20190412, it’s somewhere in-between the 3.3 and 3.4 performance, but still slower then 3.3.4000 by a noticeable margin

I’m running TSS_DEBUG=5002 code-insiders . on build Version 1.36.0-insider (1.36.0-insider) and when I go to about:inspect in Chrome don’t see anything there.

I do think this may still be related this this slowdown: https://github.com/microsoft/TypeScript/issues/29949

Not to bitch but perhaps it helps, my current setup is quite borked between https://github.com/microsoft/vscode/issues/25312 and this, I’m restarting TS server many times a day, waiting 20+ seconds for it to load, and when it does run it’s now oftentimes 5+ seconds delayed (on a 2.9 i9 quad code no less). I’d love to be of any help to get some of this figured out!

Yeah, I see a note about it, thanks for sharing @maxmathews! TBH, locally I still have better results with 3.3 version comparing to 3.5.RC, but it’s not that bad as it was for 3.4. So thanks 🙏

@havenchyk Hey man, I know you’re not asking me, but the issue seems to have been fixed with the release of Typescript 3.5.0-rc.

I believe it’s discussed a bit here: https://devblogs.microsoft.com/typescript/announcing-typescript-3-5-rc/.