[Anders Hejlsberg (ahejlsberg)]

When creating intersection types we first normalize combinations of intersection and union types to place union types topmost. For example, this process turns X & (A | B) into the equivalent X & A | X & B. The normalization process can be very costly for intersections involving large union types. With this PR we cache both unnormalized and normalized intersection types, where previously we would only cache the latter. This means that for a particular set of unnormalized input types, we will only perform the potentially expensive normalization process once.

The improved caching lowers the check times for react and styled-components by ~25% and makes our performance better than 3.3:

	3.3	3.4	Master	This PR
react	3.57s	4.25s	4.61s	3.42s
styled-components	4.70s	7.55s	5.84s	4.44s

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) test this & run dt

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the extended test suite on this PR at 2c34672. You can monitor the build here. It should now contribute to this PR's status checks.

[Anders Hejlsberg (ahejlsberg)]

TypeScript Bot (@typescript-bot) run dt

[TypeScript Bot (typescript-bot)]

Heya Anders Hejlsberg (@ahejlsberg), I've started to run the parallelized Definitely Typed test suite on this PR at 2c34672. You can monitor the build here. It should now contribute to this PR's status checks.

[Wesley Wigham (weswigham)]

Should we consider doing the same for unions, since they potentially repeatedly invoke subtype reduction and/or literal reduction when normalized (which we likewise know is costly for large unions)?

[Anders Hejlsberg (ahejlsberg)]

Should we consider doing the same for unions ... ?

I tried. It doesn't seem to make much of a difference. In fact, since UnionReduction.Literal is fairly efficient the caching actually had a negative effect (because computing keys takes time). But even when just caching UnionReduction.Subtype there wasn't a measurable effect.