-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Hard way to respect BTreeMap's minimum node length #75105
Conversation
0efb48d
to
07299aa
Compare
Flabbergasted... not that I didn't immediately realize that 3 lines of code implement the 2nd rule in #74834 and it was worth a try, but that this extra code (covering a case that I think isn't benchmarked) restores performance:
I benchmarked things again, and get the same relative results (though all the clone tests are 10% slower than they were 6 hours ago, before I rebooted my PC). So now this seems like a viable PR to me. |
07299aa
to
631a644
Compare
☔ The latest upstream changes (presumably #75329) made this pull request unmergeable. Please resolve the merge conflicts. |
631a644
to
05042de
Compare
05042de
to
17ab457
Compare
@bors r+ |
📌 Commit 17ab457 has been approved by |
@bors rollup=never |
☀️ Test successful - checks-actions, checks-azure |
Resolves #74834 the hard way (though not the hardest imaginable).
Benchmarks (which are all biased/realistic, inserting keys in ascending order) say:
This difference is not caused by the
debug_assert
-related code in the functionsplitpoint
, it's the same without.