Ternary Tree Vs Hash Table

Question

I need to know if a ternary tree is better than a hash table.

I came across this question in a reply to another question I had where someone said that ternary trees are often faster than hash tables. I found that hard to believe, so I decided to research a little into it.

This one website from Princeton appears to be the source of the belief. I took a look at algorithm which is described to be O(log n + k) where n is the number of words stored, and k is the length of the key.

It seems to me that the only way this could be faster is if you are often searching for elements that are not already stored. Another thing that bothers me, is that the non-continuous crawling of a trie would tend to cause you to hit pages that have been swapped out, but whether this is a major effect could only be seen through benchmarks.

Now I know that there are probably pros and cons to both of them, and if so, I want to know what they are. Benchmarks are also helpful.

Answer 1

Here is what I gather from the Dr. Dobbs Article reachable from the Princeton link you gave:

1. Ternary Search Trees are up to 10% faster than hash tables on some search problems. They are sometimes slower - depending vastly on the machine used.
2. TRTs are a custom data structure tuned by two of the finest minds of Computer Science - Jon Bentley and Robert Sedgewick both wrote good textbooks, and have done their share of practical programming. Hash tables are considered run-of-the-mill.
3. The constants involved are significant, as Hao Wooi Lin says.
4. Overall, this depends on the problem you are solving. The faster development time and almost ubiquitous support for hash tables in many programming languages are often more important than a ten-percent improvement in run time.

Answer 2

The only way to answer this question is empirically. The answer depends on the details of your implementation, what kinds of searches you do, what hardware you have, and what compiler you're using. You can copy the C code from Princeton. If you want to try a functional language, Standard ML has hash tables (look at SML/NJ), and here is some ML for ternary search trees:

type key = Key.ord_key
type item = Key.ord_key list

datatype set = NODE of { key : key, lt : set, eq : set, gt : set }
             | LEAF

val empty = LEAF

fun member (_, LEAF) = false
  | member (h::t, NODE {key, lt, eq, gt}) =
      (case Key.compare (h, key)
         of EQUAL   => member(t, eq)
          | LESS    => member(h::t, lt)
          | GREATER => member(h::t, gt))
  | member ([], NODE {key, lt, eq, gt}) =
      (case Key.compare (Key.sentinel, key)
         of EQUAL   => true
          | LESS    => member([], lt)
          | GREATER => member([], gt))

exception AlreadyPresent

fun insert(h::t, LEAF) =
      NODE { key = h, eq = insert(t, LEAF), lt = LEAF, gt = LEAF }
  | insert([], LEAF) =
      NODE { key = Key.sentinel, eq = LEAF, lt = LEAF, gt = LEAF }
  | insert(h::t, NODE {key, lt, eq, gt}) =
      (case Key.compare (h, key)
         of EQUAL   => NODE {key = key, lt = lt, gt = gt, eq = insert(t, eq)}
          | LESS    => NODE {key = key, lt = insert(h::t, lt), gt = gt, eq = eq}
          | GREATER => NODE {key = key, lt = lt, gt = insert(h::t, gt), eq = eq})
  | insert([], NODE {key, lt, eq, gt}) =
      (case Key.compare (Key.sentinel, key)
         of EQUAL   => raise AlreadyPresent
          | LESS    => NODE {key = key, lt = insert([], lt), gt = gt, eq = eq}
          | GREATER => NODE {key = key, lt = lt, gt = insert([], gt), eq = eq})

fun add(l, n) = insert(l, n) handle AlreadyPresent => n

Answer 3

log(n) grows slowly engough so it can often require a huge amount of data before it's slower than an O(1) algorithm when taking the constant factor into account.

Answer 4

This is pretty intriguing to me as well. But from the wiki I read, it claimed that ternary Tree is faster at most search problems. This is not surprising, because even though hash table has O(1) lookup, you still need time doing the hashing. So it's not really O(1) but more like O(k) where k do not depend on N (number of items in the data structure). This may gives the impression that Hash Table is faster. However, if you're dealing with a large structures, the k quickly adds up and there will come a point where searching speed of Hash Tables becomes slower than Ternary Tree.

Answer 5

You may have a look at tstdb: http://code.google.com/p/tstdb/

This kv-store is based on Ternary Search Tree, and it is compatible with Memcached. More over, tstdb supports prefix searching and range query which are facilitated by Ternary Search Tree.