-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Use different datastructure for MIRI relocations #50866
Conversation
Before reviewing, let's check if that actually makes things faster. @bors try |
[WIP] Use different datastructure for MIRI relocations This PR makes relocations in MIRI used a sorted vector instead of a `BTreeMap` which should make a few common operations more efficient. Let's see if that's true. r? @oli-obk
General question: do we have any way of profiling rustc? Like with cachegrind? |
☀️ Test successful - status-travis |
@Mark-Simulacrum, could I get a perf run for this, please? |
@oli-obk The perf collector supports local benchmarking with a variety of "profilers" https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector#profiling-local-builds. Perf for cff7e0f queued. |
@oli-obk @nnethercote is using cachegrind for analysing the hot spots. |
See https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector#profiling-local-builds for info on profiling rustc. |
Generally faster except NLL. |
Note that style-servo "clean incremental" builds are highly variable, and so those improvements should be ignored. So it's a slight improvement on coercions and inflate, and a slight regression on clap-rs. |
This seems like a lot of complexity for slight gains. Not sure if it's worth it? |
The complexity is in a general purpose data structures that we might want to use elsewhere too instead of BTreeMap, so I think it's fine. |
I'm not sure how trustworthy the NLL benchmarks are. |
Given that the NLL algorithm is still in development and would be improved from other fronts, I believe we could disregard the minor NLL slowdown. |
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.
oops, forgot to press the "Submit review" button
use std::mem; | ||
use std::ops::{RangeBounds, Bound, Index, IndexMut}; | ||
|
||
#[derive(Clone, PartialEq, Eq, Hash, Debug, RustcEncodable, RustcDecodable)] |
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.
Default
would probably be a good derive to have here, too
use std::ops::{RangeBounds, Bound, Index, IndexMut}; | ||
|
||
#[derive(Clone, PartialEq, Eq, Hash, Debug, RustcEncodable, RustcDecodable)] | ||
pub struct SortedMap<K: Ord, V> { |
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.
Add some docs explaining the type
} | ||
} | ||
|
||
// It is up to the caller to make sure that the elements are sorted by key |
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.
Make this a doc comment
|
||
#[inline] | ||
pub fn insert(&mut self, key: K, mut value: V) -> Option<V> { | ||
let index = self.data.binary_search_by(|&(ref x, _)| x.cmp(&key)); |
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.
use binary_search_by_key
(also in the other functions further down)
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.
Since we can't copy the key in the general case, we'd have to sort by &K
which results in:
let index = self.data.binary_search_by_key(&&key, |&(ref x, _)| x);
I'm not sure that's an improvement. I can wrap the lookup in a helper method though. That should make things nicer.
self.data.iter_mut().map(|&mut (ref mut k, _)| k).for_each(f); | ||
} | ||
|
||
// It is up to the caller to make sure that the elements are sorted by key |
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.
comment -> doc comment
r=me with a rebase |
027d376
to
dcf3c99
Compare
☔ The latest upstream changes (presumably #50520) made this pull request unmergeable. Please resolve the merge conflicts. |
…orting order which lookup relies on.
dcf3c99
to
95fac99
Compare
📌 Commit 95fac99 has been approved by |
Use different datastructure for MIRI relocations This PR makes relocations in MIRI used a sorted vector instead of a `BTreeMap` which should make a few common operations more efficient. Let's see if that's true. r? @oli-obk
☀️ Test successful - status-appveyor, status-travis |
/// It is up to the caller to make sure that the elements are sorted by key | ||
/// and that there are no duplicates. | ||
#[inline] | ||
pub fn insert_presorted(&mut self, mut elements: Vec<(K, V)>) { |
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.
Couldn't this take a SortedMap
?
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.
It could, yes.
for k in keys { | ||
alloc.relocations.remove(&k); | ||
} | ||
alloc.relocations.remove_range(first ..= last); |
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 don't think this is doing what it's supposed to be doing. Writing to the first element of a (&(), &())
00 00 00 00 00 00 00 00
|-----4----||-----5-----|
will result in
00 00 00 00 00 00 00 00
|-----9----|
I have a fix incoming
This PR makes relocations in MIRI used a sorted vector instead of a
BTreeMap
which should make a few common operations more efficient. Let's see if that's true.r? @oli-obk