8

Has anyone seen an implementation of the STL where stl::set is not implemented as a red-black tree?

The reason I ask is that, in my experiments, B-trees outperform std::set (and other red-black tree implementations) by a factor of 2 to 4 depending on the value of B. I'm curious if there is a compelling reason to use red-black trees when there appear to be faster data structures available.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
Pat Morin
  • 1,688
  • 1
  • 12
  • 12
  • I'm not an algorithms expert by any means, but `std::set` and friends come with stringent maximum complexity ("big-O") requirements set by the standard. Would an alternative implementation meet all of these requirements? – Tristan Brindle Oct 24 '14 at 15:02
  • you can have a look here: [Why you shouldn't use set (and what you should use instead)](http://lafstern.org/matt/col1.pdf). – davidhigh Oct 24 '14 at 15:09
  • @TristanBrindle: Yes. B-2B trees give the same complexity guarantees. (In fact, red-black trees are actually a simulation of 2-3-4 trees using binary trees; this makes them more complicated and slower.) – Pat Morin Oct 24 '14 at 15:19
  • 1
    @davidhigh: I did see that document in my searches. It doesn't answer my question. It suggests using linear update/search time data structures instead of the O(log n) time structures. That's fine if you don't intend to do many searches or modifications, but stl::set still fills a pretty important role in the STL. – Pat Morin Oct 24 '14 at 15:24

2 Answers2

13

Some folks over at Google actually built a B-tree based implementation of the C++ standard library containers. They seem to have much better performance than standard binary tree implementations.

There is a catch, though. The C++ standard guarantees that deleting an element from a map or set only invalidates other iterators pointing to the same element in the map or set. With the B-tree based implementation, due to node splits and consolidations, the erase member functions on these new structures may invalidate iterators to other elements in the tree. As a result, these implementations aren't perfect replacements for the standard implementations and couldn't be used in a conformant implementation.

Hope this helps!

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
  • Aha. That's what I was looking for. I figured there had to be a catch. I didn't realize that the standard allowed for modifications to the tree when there were other iterators into the tree. This is a pretty non-standard use-case though. It should be possible to hack around it when it occurs. – Pat Morin Oct 24 '14 at 17:02
  • 1
    Reading up on the page you pointed to, I see they thoughtfully already provided such a hack: https://code.google.com/p/cpp-btree/wiki/UsageInstructions#Safe_B-Tree_maps_and_sets – Pat Morin Oct 24 '14 at 17:47
4

There is at least one implementation based on AVL trees instead of red-black trees.

I haven't tried to verify conformance of this implementation, but at least (unlike a B-tree based implementation) it at least could be written to conform perfectly to the requirements of the standard.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • 1
    I'm not sure AVL trees will do; `insert` and `erase` require amortized constant modification times when changing a known location, and AVL trees don't supply this. – jbapple Oct 26 '14 at 16:36
  • Unfortunately it is GNU GPL licensed. – plasmacel Nov 02 '17 at 14:06