4 ms·
The issue is not just that it's ‘slow’, but that it's frequently slower even than std::map. My suspicion is that the issue is its use of power-of-2 sizes, which
by Veedrac 8y ago
The issue is not just that it's ‘slow’, but that it's frequently slower even than std::map. My suspicion is that the issue is its use of power-of-2 sizes, which is a terrible idea for binary search because it causes cache line aliasing. This is discussed in a lot of detail by Paul Khuong.
https://www.pvk.ca/Blog/2012/07/30/binary-search-is-a-pathological-case-for-caches/ https://www.pvk.ca/Blog/2012/07/30/binary-search-is-a-pathol...
> Even without that hurdle, the slowdown caused by aliasing between cache lines when executing binary searches on vectors of (nearly-)power-of-two sizes is alarming. The ratio of runtimes between the classic binary search and the offset quaternary search is on the order of two to ten, depending on the test case.
The approaches there are likely to give significant speedups.
- kevingadd 8y agoYeah, in my past experience if my sizes for my B-tree were too close to powers of 2 the performance would tank. Adjusting them to be no where near a power of two and also not take up too many cache lines was the ticket for me.