-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix #19907: Skip soft unions in widenSingle of widenInferred #19995
Conversation
test performance please |
test performance please |
performance test scheduled: 149 job(s) in queue, 1 running. |
Performance test finished successfully: Visit https://dotty-bench.epfl.ch/19995/ to see the changes. Benchmarks is based on merging with main (a36849f) |
val widenedFromUnion = widenOr(widenedFromSingle) | ||
val widenedFromUnion = | ||
if widenUnions && typeSize(inst) > 64 then | ||
// If the inferred type `inst` is too large, the subtype check for `bound` in `widenSingle` |
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.
Very useful diagnosis! I think we can even go further: If we have widenUnions
then we never need to widen singletons in soft unions, since we will do an OrDominator afterwards, and this is the same for original or widen types. We don't even need a size limit for this.
I'll push a commit that tries this.
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.
Correction: It does not work since we sometimes leave original orType if it is transparent, and then we should ideally widen singleton types.
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 could fix it and account for transparent unions. See latest commit.
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.
Thanks, I updated the title.
test performance please |
performance test scheduled: 139 job(s) in queue, 1 running. |
Performance test finished successfully: Visit https://dotty-bench.epfl.ch/19995/ to see the changes. Benchmarks is based on merging with main (a36849f) |
Passing on to @smarter for final comments or approval. |
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.
Otherwise LGTM.
Replace mergeIfSuper by a different algorithm that is more efficient. We drop or-summands in both arguments of a lub that are subsumed by the other. This avoids expensive recursive calls to lub or expensive comparisons with union types on the right. I tested the previous performance regression #19907 with the new algorithm, and without the changes in #19995 that avoid a slow lub. Where previously it took minutes it now compiles fast. Specifically, we get for i19907_slow_1000_3.scala: 2.9s with the optimizations in #19995, 3.3s with just this PR. And for i19907_slow_1000_4.scala: 3.9s with the optimizations in #19995, 4.5s with just this PR. So the optimizations in #19995 are much less critical now since lubs are much faster. Still, it's probably worthwhile to leave them in in case there is a humongous program that stresses lubs even more.
Fix #19907.
If the inferred type
inst
is too large, the subtype check forbound
inwidenSingle
can be expensivedue to comparisons between large union types, so we avoid it by skipping soft unions in the first step.
Singletons of soft unions are widened when we
widenUnion
now.