
B-tree vs. Binary Search Tree - soundsop
http://attractivechaos.wordpress.com/2008/09/24/b-tree-vs-binary-search-tree/
======
jacobscott
"I studied this source codes and think I should be able to further optimize
it. In the end, I got my kbtree.h macro library. As you can see in my hash
table benchmark, the modified version beats STL set while using even smaller
memory than the original version."

I don't see any such benchmarks in the article, which makes any claims not
very useful.

------
bdfh42
A nice explanation of what this is all about is one written by Rod Stephens at
<http://www.devx.com/dotnet/Article/38097>

------
litewulf
I'm rather unimpressed by a linear reduction in memory consumption. Mostly
because its linear, and its "easy" to scale linearly (its called going and
buying more RAM!)

~~~
anamax
> Mostly because its linear, and its "easy" to scale linearly (its called
> going and buying more RAM!)

It's only easy if your system isn't maxed or if your data segment isn't
already at its limits. (64 bit addresses cause yet another round of bloat.)

~~~
litewulf
My point here is that linear improvements don't really improve your scaling or
performance in any real sense. Linear improvements are equivalent to buying
hardware (or sharding), whereas I think the kind of really nice improvement
you want is say changing an exponential factor. Because thats the kind of
improvement you can't compete with by buying hardware.

That being said, for a large enough server farm, yes, linear improvements are
totally beneficial. (And a small enough server farm.) But its important to
keep in perspective that not all betters are created equal ;)

------
michael_dorfman
I think the various criticisms listed here are all valid (lack of benchmarks
renders performance claims dubious, linear reduction in RAM is not that big a
deal) but I still think it's worth the reminder that B-trees (and other
alternatives to Binary Search Trees) are around. It's easy to get in familiar
ruts with data structures....

