-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Hard way to respect BTreeMap's minimum node length #75105
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
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.