There are plenty of fast non-linear hash functions you can use. The FNV example you mentioned is lame (doesn’t match actual recommended implementation with xor ops). Both Hsieh’s and Jenkins hashes are strongly resistant to collisions and can take a random initial seed, which makes collision attacks practically impossible.

Regarding speed. Properly implemented hash tables are typically much faster. here are some numbers: http://google-sparsehash.googlecode.com/svn/trunk/doc/performance.html

Regarding ease of implementation of left leaning red-black tree. Jason Evans doesn’t seem agree with you after actually implemented one:
http://www.canonware.com/~ttt/2008/04/left-leaning-red-black-trees-are-hard.html

Without seeing any of your code, I’d believe Jason Evans more, given his contribution to FreeBSD libc, specifically a high performance malloc implementation.

My recommendation is simple: if you want a dynamic ordered set/map, use a good red-black tree implementation. If you want an unordered set/map, use a linear probe hash table (for example, Google’s dense_hash_set/map for speed and sparse_hash_set/map for space advantages) with Hsieh and Jenkin’s hash with a random seed.

Your arguments would be a lot more interesting if you posted working code and benchmark numbers.

In some cases, your input is already a hash value. For example, we use MD5 hashes to uniquely identify the contents of data records (some of which may be stored on disk, not in memory). We use this both for eliminating redundant records, but also as the unique identifier for storing references to specific records. Given that we already have a nice high-quality hash value computed for other reasons, placing information about the records in a hash table is a no-brainer.

Your argument against the FNV hash is a straw man. The specific recommendation from the authors of that hash for using a table with a smaller number of bits is to do XOR folding (shift the higher order bits down and XOR them with the low order bits). That invalidates your claim that FNV won’t affect the low order bits (at least if used as recommended). Now maybe the Microsoft hash implementation doesn’t do that, but you can’t say the authors of FNV didn’t warn them!

I agree that for general purpose use, a binary tree is better (and 99.5% of the time, I just use std::set or std::map for my purposes), but in some cases, hash tables are an excellent solution.

In my 14 years a professional programmer, and 30-some years programming, I’ve yet to meet a hash table implementation that avoided all of the problems I outlined (including, I comment, the multiple implementations I’ve written). And, in that time, outside of some homework problems, I’ve yet to see a balanced tree implementation that didn’t get balancing right. Primarily because if you don’t get balancing right, this becomes obvious real quick- while if your hash function has a linear congruence causing a high rate collisions on certain common data patterns, you can easily miss that.

As for explaining the theoretical underpinnings of the two data structures, go read Knuth.

The only thing that made sense was the O(N) resize that will occur once in a while. Someone already pointed out that you can spread that cost if it’s really that big.

Joshua Haberman already pointed out these problems, I just got pissed off badly enough that I thought a restating was necessary. I can see now… wanna be programmer decides not to use hash tables because he read somewhere they have a lot of problems.

The article should have focused either on the theoretical underpinnings of both hash tables and binary trees (as Bob Foster comments, hash tables win hands down), or on actual implementations. (In which case I still doubt binary trees would have won… balancing is *hard*.)

Finally… I *have* to comment on what Amit says. “There really is no substitute for knowing what one is doing, in programming or anything else.” Yeah. Well said. Too bad it’s shortly followed by “…hash tables have to compute the hash and then do a linear search by comparison”, huh?

Also if you are concerned about collisions, cuckoo hashing (or a generalization thereof) might be worth looking at. It’s very simple to implement and greatly reduces the probability of collisions.

As it seems to have bothered people, I’ve fixed the spelling on amortized, at least where I saw it. Editing on the web sucks (’cmon, people- search and replace? Over the whole text box, not just the portion on the screen? Is that so much to ask?).

Dealing with the cost of cache misses greatly increases the complexity of the cost analysis. One thing to remember: it’s not just the cost of the cache misses of the data, it’s also the cost of the cache misses of the code. As a general rule, more code = more complexity = more cache misses, but these are not linear relationships (chaotic, more like). One of the things I like about binary trees is that they’re simple. Which means both that they’re much less likely to be wrong, and the code tends to be smaller as well.

If I said B-trees, I really meant Binary trees- the classic root node, two subtrees, and some balancing information. Weight balanced, height balanced, red-black trees- they all have their pluses and minuses.

The end was rather abrupt- the problem was that I realized that I had just opened a can of worms that would require more verbage than I’d already written. Do I write another Galois-field introduction? Also, the glaring hole was what hash function do I use? Up until recently, I generally used a linear feedback shift register- which, while it has it’s own linear recurrances, these tend to be less common in the wild than with modulo-based hash functions. I have some ideas on a new hash function, but I want to make sure it’s a decent one before publishing it (to limit the amount of crow I’ll be required to consume).

Now to more specific responses:
Ian Clark: I like skip lists too, at least as a mutable data structure. But notice that they have O(log N) bounds as well- and binary trees keep elements in sorted order as well (and weight balanced trees allow you to get the i-th element in O(log N)).

Damien Morton: I said if the hash function is 10x slower than the compare function. Some hash functions (and some compare functions) are going to be more or less expensive. For example, cryptographically secure hash functions tend to be way more expensive. But my experience has been that 10x is about average for hash function costs vr.s compare function costs, and maybe even generous to the hash function. Consider that 1) the compare function doesn’t need to compare the whole structures, it can stop the first time it finds a difference, 2) most compare functions work on words as well, not just bytes, and 3) compare is a very cheap operation (basically a subtraction). Vr.s the multiplications and modulos and table lookups commonly found in hash functions.

Sriram Srinivasan: I was trying desperately to avoid mentioning purely applicative data structures, so I didn’t mention multithreading concerns, but you’re right: the thread behavior of tree based data structures is much nicer than that of hash table based data structures- for lots of reasons.

Leon Mergen: Given that a recent version of Visual Studio C++ used FNV, I wouldn’t gaurentee that simply because it’s a mature environment that hash tables are implemented correctly.

Jasper: I agree with this idea- except I’d go the other way. Start by using binary trees, and switch to hash tables when it’s been shown that binary trees are too slow. The reason for this is because binary trees have a much more predictable performance envelope. You want the failure mode to happen early and where you can see it. For example, operations on binary trees with a billion elements are only 3x slower than operations on binary trees with a thousand elements. It’s generally easy in testing to get situations where you have a thousand elements in the binary tree- if you observe that it’s 3x fast enough, you’re done- even if, from some insane congruence of events, the code gets a billion elements in the tree, it’s still fast enough. Hash tables are real fast- right up until they’re not. Also, the performance of binary trees is not heavily affected by the data in the binary tree- notice how many of my gotchas on hash tables are data-dependent.

Bob Foster: No, you won’t see the failure modes. Because the performance failures of hash tables are data or situation dependent. Which are very easy to miss in testing, and, in my experience, only rear their ugly heads out in the field. At 3AM Sunday morning. At the important customer’s site. In outer Mongolia. OK, I’m exagerating here, but not by much.

mschaef: I need to write a post about the multi-threaded potientials of hash tables vr.s trees. But by far the biggest advantage I see for trees is that I can implement them purely applicatively and have only one word of transactional memory associated with them. But that’s a radically different blog post.

Grrate poste!