-
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
Make sure synthetic apply methods are generated in deterministic order #18210
Make sure synthetic apply methods are generated in deterministic order #18210
Conversation
Function1SpecializedReturnTypes | ||
|
||
@tu lazy val Function1SpecializedParamClasses: PerRun[collection.Set[Symbol]] = | ||
@tu lazy val Function1SpecializedParamClasses: PerRun[List[Symbol]] = |
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.
We do rely on a fast contains
operation on some of these.
Maybe we could type them as collection.Set
and implement them with collection.mutable.LinkedHashSet
.
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.
How large can those sets grow? Which is the largest one?
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.
Those can indeed get relatively large, like I think 216 elements for Function2SpecializedApplyNames
. I changed those back to Set
s, AFAICS now lists are used for iterating over and sets are used for contains
checks. I'm not so familiar with PerRun
though, does that look OK?
If you like this fix, you should put a test on it. Otherwise the next performance binge might rebreak it. |
e7ea119
to
6d1ae5a
Compare
Fair ;) - it's a bit of an awkward thing to test, but |
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
Fixes scala#17330 Co-Authored-By: Nicolas Stucki <[email protected]>
6d1ae5a
to
03a7ba5
Compare
Follow-up on apache#855 Gets us the fix for scala/scala3#18210
Fixes #17330