Uh oh!
There was an error while loading. Please reload this page.
Improve btree's unwrap_unchecked - #74693
Conversation
rust-highfive
commented
Jul 23, 2020
(rust_highfive has picked a reviewer for you, use r? to override) |
bors
commented
Jul 28, 2020
☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts. |
nbdd0121
commented
Aug 7, 2020
Link to the likely root cause #74615. |
LeSeulArtichaut
commented
Aug 22, 2020
Does someone from |
Mark-Simulacrum
commented
Sep 9, 2020
I am inclined to not try and change unwrap_unchecked since it seems likely that the improvements are optimizer noise (e.g., will be regressed/improved for various changes just because of slightly different inlining decisions and such), so I am going to close this, but if people feel differently feel free to reopen/let me know. |
ssomers
commented
Sep 9, 2020
Ralf seemed to like the added doc comment, when I split this off of some other PR. |
Mark-Simulacrum
commented
Sep 9, 2020
I am happy to accept the doc comment (either in this PR, reopened and adjusted, or a new one). That would be a quick review too :) |
ssomers
commented
Sep 9, 2020
Can't reopen so another 5 digit issue number sacrificed. |
…ulacrum Document btree's unwrap_unchecked rust-lang#74693's second wind
…ulacrum Document btree's unwrap_unchecked rust-lang#74693's second wind
The seemingly optimized function
unwrap_uncheckedused in btree code appears to be slower than standardunwrap. Redirecting tounwrapas in this PR, we get some juicy improvements:But this is also an opener for the obvious question: why?
inline(always)toinlinemakes no difference.inlinealtogether has a terribly negative impact on many tests (up to factor 5) except a 40% improvement on clone tests.unwraptakes twice as long asunwrap_or_else(|| unreachable_unchecked()))for small and big option contents.unwrap_uncheckedcall in a DropGuard that is averse to panic, but changing that alone doesn't change performance.Putting on draft because it's weird and because it interferes with #73971.