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

Avoid unnecessary under-constrained implicit searches #14353

Merged
merged 1 commit into from Jan 26, 2022

Conversation

smarter
Copy link
Member

@smarter smarter commented Jan 25, 2022

In some situations we only call constrainResult for its side-effects
and ignore its result, but constrainResult calls
necessarilyCompatible which will call viewExists as a last-try.
Since viewExists doesn't have side-effects we might as well skip it,
and it turns out that using NoViewsAllowed.constrainResult does
exactly that.

This leads to a significant speed-up (from ~8s to sub-second with a hot
compiler) with the test case from #14333 (most likely this is because at
the point where we call constrainResult we haven't accumulated any
constraint from the arguments of the application, so implicit search is
free to go on a wild goose chase).

I also removed obsolete comments in this method.

Fixes #14333.

@smarter
Copy link
Member Author

smarter commented Jan 25, 2022

test performance please

@dottybot
Copy link
Member

performance test scheduled: 3 job(s) in queue, 1 running.

In some situations we only call `constrainResult` for its side-effects
and ignore its result, but `constrainResult` calls
`necessarilyCompatible` which will call `viewExists` as a last-try.
Since `viewExists` doesn't have side-effects we might as well skip it,
and it turns out that using `NoViewsAllowed.constrainResult` does
exactly that.

This leads to a significant speed-up (from ~8s to sub-second with a hot
compiler) with the test case from scala#14333 (most likely this is because at
the point where we call `constrainResult` we haven't accumulated any
constraint from the arguments of the application, so implicit search is
free to go on a wild goose chase).

I also removed obsolete comments in this method.

Fixes scala#14333.
@dottybot
Copy link
Member

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/14353/ to see the changes.

Benchmarks is based on merging with master (a83a0a7)

Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me. Nice SLA 😄

Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch

@odersky odersky merged commit 25cdd57 into scala:master Jan 26, 2022
@odersky odersky deleted the fix-i14333 branch January 26, 2022 14:49
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.

Compilation is very slow on some files due to implicit search repeatedly diverging
4 participants