-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Micro-optimize InferCtxt::replace_bound_vars_with_placeholders
by avoiding unnecessary allocation
#96021
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
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit f764286 with merge 91117d057a604d5dd404a883f9714ef5d5588d8d... |
|
||
// If there were higher-ranked regions to replace, then actually create | ||
// the next universe (this avoids needlessly creating universes). | ||
if !map.is_empty() { |
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.
Wait...is this wrong?
I think this should be taking into account types and consts too...
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.
Do we see bound types in practice? Like other than in canonical queries, which I assume we liberate elsewhere? (maybe not)
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 don't :) At least not much today. Which is likely why this isn't doesn't fail everywhere. But in the future, we'll probably see more.
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.
Is the wrongness pre-existing? This change looks ok to me from a mechanical refactoring point of view, but I don't know much about this code in general.
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.
Yeah, looks preexisting.
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.
So do you have any concern with this PR being merged?
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.
Nope! But someone (probably me) should file an issue so this doesn't get forgotten.
☀️ Try build successful - checks-actions |
Queued 91117d057a604d5dd404a883f9714ef5d5588d8d with parent 0d13f6a, future comparison URL. |
Finished benchmarking commit (91117d057a604d5dd404a883f9714ef5d5588d8d): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Footnotes |
Another weird performance result... I don't know what's happening. This change really seems like it should be a straight win. |
We had some weird CI perf results in other PRs last week. Let's try this one again. @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit f764286 with merge 2ada63cfb077a0ca6434451a2d4f6bd5e3367450... |
☀️ Try build successful - checks-actions |
Queued 2ada63cfb077a0ca6434451a2d4f6bd5e3367450 with parent 3e69bda, future comparison URL. |
Finished benchmarking commit (2ada63cfb077a0ca6434451a2d4f6bd5e3367450): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Footnotes |
#97345 landed recently. It entirely removes a great chunk of the compiler's work for |
Showed up hot in a callgrind profile of compiling
bitmaps-3.1.0
replace_bound_vars
allocates aBTreeMap
that was only used for an.is_empty()
check. This PR replaces the map with a simpleboolean
.Local benchmarks:
Primary benchmarks
Secondary benchmarks
r? @nnethercote