Skip to content

Cache unnormalized intersection types#31476

Merged
ahejlsberg merged 2 commits into
masterfrom
cacheUnnormalizedIntersections
May 21, 2019
Merged

Cache unnormalized intersection types#31476
ahejlsberg merged 2 commits into
masterfrom
cacheUnnormalizedIntersections

Conversation

@ahejlsberg
Copy link
Copy Markdown
Member

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

@ahejlsberg
Copy link
Copy Markdown
Member Author

@typescript-bot test this & run dt

@typescript-bot
Copy link
Copy Markdown
Collaborator

typescript-bot commented May 20, 2019

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

@ahejlsberg
Copy link
Copy Markdown
Member Author

@typescript-bot run dt

@typescript-bot
Copy link
Copy Markdown
Collaborator

typescript-bot commented May 20, 2019

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

@ahejlsberg ahejlsberg added this to the TypeScript 3.5.1 milestone May 20, 2019
@weswigham
Copy link
Copy Markdown
Member

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

@ahejlsberg
Copy link
Copy Markdown
Member Author

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.

@ahejlsberg ahejlsberg merged commit 3745694 into master May 21, 2019
@ahejlsberg ahejlsberg deleted the cacheUnnormalizedIntersections branch May 21, 2019 13:42
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 21, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants