-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
BTree: lazily locate leaves in rangeless iterators #86031
Conversation
This comment has been minimized.
This comment has been minimized.
About alloc's own benches:
|
This comment has been minimized.
This comment has been minimized.
2dab5be
to
9e1ac54
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 9e1ac543d134a115fe253691eb9b137192560b7a with merge ae3cf1a90b2081be4fab0ca50bf8e1c75877a29d... |
☀️ Try build successful - checks-actions |
Queued ae3cf1a90b2081be4fab0ca50bf8e1c75877a29d with parent 35fff69, future comparison URL. |
Finished benchmarking try commit (ae3cf1a90b2081be4fab0ca50bf8e1c75877a29d): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
9e1ac54
to
0272c3a
Compare
Last commits fix variance and try to maintain #[inline] placement, which seems to dominate performance. |
This comment has been minimized.
This comment has been minimized.
0272c3a
to
1e977a7
Compare
☔ The latest upstream changes (presumably #86520) made this pull request unmergeable. Please resolve the merge conflicts. |
1e977a7
to
35d02e2
Compare
@bors try @rust-timer queue Seems generally OK, though I wonder if the performance regressions are largely down to slightly more complicated code. The theoretical improvement from avoiding the extra traversal (in practice usually just one, I imagine; most iterators are likely traversed at least a few times) is worth the possible compile time overheads... |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 35d02e2 with merge d3ac1a943e62f13e360607ac74b33332a0916f76... |
☀️ Try build successful - checks-actions |
Queued d3ac1a943e62f13e360607ac74b33332a0916f76 with parent 8d57c0a, future comparison URL. |
Finished benchmarking try commit (d3ac1a943e62f13e360607ac74b33332a0916f76): comparison url. Summary: This benchmark run did not return any significant changes. 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. @bors rollup=never |
@bors r+ |
📌 Commit 35d02e2 has been approved by |
I don't understand what you're referring to (but I don't have to). It's always about just one (multi-level) traversal, and one that's going to be done anyway if iterating to the end. For huge trees, iterating to the end could save multiple memory fetches of nodes that get bored in the cache and leave, before they're read for real, but then it's a huge tree anyway, and just traversing to the fixed first leaf node is wasteful. As to the slightly more complicated code, it should allow reverting #81486. |
☀️ Test successful - checks-actions |
…r=Mark-Simulacrum BTree: merge the complication introduced by rust-lang#81486 and rust-lang#86031 Also: - Deallocate the last few tree nodes as soon as an `into_iter` iterator steps beyond the end, instead of waiting around for the drop of the iterator (just to share more code). - Symmetric code for backward iteration. - Mark unsafe the methods on dying handles, modelling dying handles after raw pointers: it's the caller's responsibility to use them safely. r? `@Mark-Simulacrum`
BTree iterators always locate both the first and last leaf edge and often only need either one, i.e., whenever they are traversed in a single direction, like in for-loops and in the common use of
iter().next()
oriter().next_back()
to retrieve the first or last key/value-pair (#62924). It's fairly easy to avoid because the iterators with this disadvantage already are quite separate from other iterators.r? @Mark-Simulacrum