Dial down detail of B-tree description by hkBst · Pull Request #135761 · rust-lang/rust (original) (raw)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the context of comparison against BST, anything more than one key per node is a "larger node". You're right that the granularity of memory/storage access (cache lines in main memory, block/page size for disks) is a useful rule of thumb. Larger nodes also make insertion and deletion more expensive. But you're mistaken about search complexity: as the existing comments note, you can maintain optimal number of comparisons (up to a small constant factor) by doing binary search in each node. Sometimes that turns out a bit slower than a linear search, but it's competitive or superior in other cases.

In any case, I don't think it's useful to try and communicate these nuances in the BTreeMap docs.