unsafe fn find_upper_bound_index<'r, Q>(
        &self,
        bound: SearchBound<&'r Q>,
        start_index: usize,
    ) -> (usize, SearchBound<&'r Q>)
    where
        Q: ?Sized + Ord,
        K: Borrow<Q>,
    {
        match bound {
            Included(key) => match unsafe { self.find_key_index(key, start_index) } {
                IndexResult::KV(idx) => (idx + 1, AllExcluded),
                IndexResult::Edge(idx) => (idx, bound),
            },
            Excluded(key) => match unsafe { self.find_key_index(key, start_index) } {
                IndexResult::KV(idx) => (idx, AllIncluded),
                IndexResult::Edge(idx) => (idx, bound),
            },
            AllIncluded => (self.len(), AllIncluded),
            AllExcluded => (start_index, AllExcluded),
        }
    }
A map based on a [B-Tree].

B-Trees represent a fundamental compromise between cache-efficiency and actually minimizing
the amount of work performed in a search. In theory, a binary search tree (BST) is the optimal
choice for a sorted map, as a perfectly balanced BST performs the theoretical minimum amount of
comparisons necessary to find an element (log<sub>2</sub>n). However, in practice the way this
is done is *very* inefficient for modern computer architectures. In particular, every element
is stored in its own individually heap-allocated node. This means that every single insertion
triggers a heap-allocation, and every single comparison should be a cache-miss. Since these
are both notably expensive things to do in practice, we are forced to at very least reconsider
the BST strategy.

A B-Tree instead
benchmarks/haystacks/code/rust-library.rs