-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Optimize substitution types #50397
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
Optimize substitution types #50397
Conversation
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the abridged perf test suite on this PR at a4a9ede. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at a4a9ede. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at a4a9ede. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the diff-based user code test suite on this PR at a4a9ede. You can monitor the build here. Update: The results are in! |
@ahejlsberg Here are the results of running the user test suite comparing Something interesting changed - please have a look. Details
|
@ahejlsberg Here they are:Comparison Report - main..50397
System
Hosts
Scenarios
Developer Information: |
Heya @ahejlsberg, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at e73d268. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the diff-based user code test suite on this PR at e73d268. You can monitor the build here. |
Heya @ahejlsberg, I've started to run the abridged perf test suite on this PR at e73d268. You can monitor the build here. Update: The results are in! |
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at e73d268. You can monitor the build here. |
Heya @ahejlsberg, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
@ahejlsberg Here they are:Comparison Report - main..50397
System
Hosts
Scenarios
Developer Information: |
function getSubstitutionType(baseType: Type, substitute: Type) { | ||
if (substitute.flags & TypeFlags.AnyOrUnknown || substitute === baseType) { | ||
function getSubstitutionType(baseType: Type, constraint: Type) { | ||
if (constraint.flags & TypeFlags.AnyOrUnknown || constraint === baseType || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
constraint === baseType
Is this just when someone writes
T extends T ? TrueType<T> : FalseType<T>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume so. The check was already there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you be able to write a few tests that are known to trigger the new behavior? This gives a few good example cases to better understand the changes now and in the future too, and ensure we don't regress.
@typescript-bot user test this inline |
This PR optimizes creation and instantiation of substitution types. Two main changes:
Substitution types previously stored the substitute type as an intersection between the base type and the constraint being added. These components are now stored separately (in
baseType
andconstraint
properties) and intersected when needed. The separation enables a more efficient check for whether an instantiated substitution type should be preserved or resolved to its base type: Peviously this check compared the base type to the full substitution intersection, it now just compares the base type to the constraint. This turned out to be the origin of the relation cache overflow inRangeError: Map maximum size exceeded
withtypescript@4.8.1-rc
#50290.Due to some erroneous logic in
getTypeFromIndexedAccessTypeNode
, previously we would stack two substitution types on top of each other for indexed access types. This created a lot of unnecessary work.With these optimizations, the check time for the repro in #50290 drops from 11.2s to 5.2s, a greater than 50% reduction! I imagine other projects that contain complicated conditional types may see a similar benefit.
Fixes #50290.