Improve rebuilding behaviour of BinaryHeap::retain. #78681
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @kennytm (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @Amanieu |
|
r? @KodrAus |
|
This looks good to me! But it would be nice to see a microbenchmark or two to get an idea of what kind of a difference it makes. |
|
☔ The latest upstream changes (presumably #77435) made this pull request unmergeable. Please resolve the merge conflicts. |
|
returning to author to address the merge conflict |
|
r? @Amanieu |
|
r=me once the merge conflict is fixed. |
|
ping @m-ou-se Can you resolve the merge conflict so that we can merge this? |
It now doesn't fully rebuild the heap, but only the parts that are necessary.
3ffb493
to
f5d72ab
Compare
|
Thanks for the reminder! @bors r=Amanieu |
|
📌 Commit f5d72ab has been approved by |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Apr 22, 2021
Improve rebuilding behaviour of BinaryHeap::retain. This changes `BinaryHeap::retain` such that it doesn't always fully rebuild the heap, but only rebuilds the parts for which that's necessary. This makes use of the fact that retain gives out `&T`s and not `&mut T`s. Retaining every element or removing only elements at the end results in no rebuilding at all. Retaining most elements results in only reordering the elements that got moved (those after the first removed element), using the same logic as was already used for `append`. cc `@KodrAus` `@sfackler` - We briefly discussed this possibility in the meeting last week while we talked about stabilization of this function (rust-lang#71503).
|
☀️ Test successful - checks-actions |
clint-white
added a commit
to clint-white/binary-heap-plus-rs
that referenced
this pull request
Aug 7, 2022
This commit ports the change in the rebuild heuristic used by `BinaryHeap::append()` that was added in rust-lang/rust#77435: "Change BinaryHeap::append rebuild heuristic". See also the discussion in rust-lang/rust#77433: "Suboptimal performance of BinaryHeap::append" for more information on how the new heuristic was chosen. It also ports the new private method `.rebuild_tail()` now used by `std::collections::BinaryHeap::append()` from rust-lang/rust#78681: "Improve rebuilding behaviour of BinaryHeap::retain". Note that Rust 1.60.0 adds the clippy lint `manual_bits` which warns against code used here. We suppress the lint instead of following the upstream patch which now uses `usize::BITS`, since this was stabilized in Rust 1.53.0 and this crate's MSRV is currently 1.36.0.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes
BinaryHeap::retainsuch that it doesn't always fully rebuild the heap, but only rebuilds the parts for which that's necessary.This makes use of the fact that retain gives out
&Ts and not&mut Ts.Retaining every element or removing only elements at the end results in no rebuilding at all. Retaining most elements results in only reordering the elements that got moved (those after the first removed element), using the same logic as was already used for
append.cc @KodrAus @sfackler - We briefly discussed this possibility in the meeting last week while we talked about stabilization of this function (#71503).