Many mentions of things being too slow and other things being high performance. I'm not doubting the truthfulness, but it would have been really nice to see some hard numbers that show the magnitude of improvement in a scenario or two.
Many mentions of things being too slow and other things being high performance. I'm not doubting the truthfulness, but it would have been really nice to see some hard numbers that show the magnitude of improvement in a scenario or two.
Also, it's very hard to make a b+tree that is ever faster than other data-structures in RAM.
Obviously if you don't need (or only rarely need) in-order traversing (or related operations like successor), hash-tables are very fast.
If you do need in-order traversing, for small amounts of data, sorted arrays are very fast, and for large amounts of data various types of prefix-tries do very well.
If you ever write a blog post about these things, I'd love to see some measurements! :-)
Yeah, I really should put something out there. It may be that my b+trees are suboptimal, and some sunlight on it would help.
Measurements of actual implementations make for fruitful, constructive discussion. Doesn't need to be perfect to be useful and interesting. Hope to see it on the front page!
Yeah, this is some weird "performance" optimizer that half-misuses terminology and complains that using an underlying container is bad for implementing their own basic container.
Eh yes, you're implementing your basic container, naturally a basic container won't cut it.