Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache unnormalized intersection types #31476

Merged
merged 2 commits into from May 21, 2019
Merged

Conversation

ahejlsberg
Copy link
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
Member Author

@typescript-bot test this & run dt

@typescript-bot
Copy link
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
Member Author

@typescript-bot run dt

@typescript-bot
Copy link
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
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
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants