-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Flatten immediately nested conditional types in the false position #36583
Conversation
|
I've thrown up #36584 as a much simpler alternative - there's no hard syntactic requirements (so it will take effect much more often than this change), it doesn't contort conditional instantiation with an inner loop, and allows the same usecases. In the cases where we would flatten here, we already don't create anything intermediate that isn't used to determine simplifyability (at least once distributivity is handled/bailed appropriately); so beyond acting as a trampoline to reduce stack depth in certain scenarios, I don't think the extra structure here serves much purpose, other than to greatly complicate the code. Ergo, I think the onus is really on this change to demonstrate a case where the extra structure actually saves us from a pathological performance cliff. |
@weswigham Beyond fixing the depth limiter issue on large conditional types, the PR makes resolution faster by virtue of its shortened code path and reduces memory consumption by not storing resolved types in the caches associated with the each nested type's |
I think that unless this pattern is super-widespread (and it's not because we made it an error), it's really not worth giving this treatment to. I'd get giving this treatment to, like, nested object instantiation somehow, but syntactically nested conditionals are few and far between. There's a grand total of one type in the react .d.ts which would save one callstack depth for this. I feel a change like this change is just way too narrow to justify, at least without very concrete cases that it fixes and the effect it has on them. |
I don't think this change is that complicated. Disregarding whitespace changes and new comments, it's the same length as #36584 -- about 10 lines.
|
…ntactic requirements or implementation contortions Extract logic into function
@ahejlsberg I've finished merging #36584 into this PR, and also merged with @typescript-bot test this |
Heya @weswigham, I've started to run the parallelized community code test suite on this PR at e59c3e6. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @weswigham, I've started to run the extended test suite on this PR at e59c3e6. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @weswigham, I've started to run the parallelized Definitely Typed test suite on this PR at e59c3e6. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @weswigham, I've started to run the perf test suite on this PR at e59c3e6. You can monitor the build here. It should now contribute to this PR's status checks. Update: The results are in! |
@weswigham Here they are:Comparison Report - master..36583
System
Hosts
Scenarios
|
@ahejlsberg This looks ready to merge, right? |
@ahejlsberg can you update this PR and then merge it? |
# Conflicts: # src/compiler/checker.ts
With this PR we flatten immediately nested conditional types in the false position, effectively treating types of the form
as a single construct for purposes of resolution. This should meaningfully improve the cost of resolving such types, plus it means they aren't subject to the instatiation depth limiter (they basically count as a single level).
Fixes #28663.