Comments on: Problems with Hash Tables http://enfranchisedmind.com/blog/posts/problems-with-hash-tables/ programming, politics, & other religious issues Mon, 15 Mar 2010 00:31:40 +0000 hourly 1 By: Brian http://enfranchisedmind.com/blog/posts/problems-with-hash-tables/#comment-37154 Brian Mon, 11 Jan 2010 18:34:46 +0000 http://enfranchisedmind.com/blog/2008/02/25/problems-with-hash-tables/#comment-37154 Anon: the problem with including caching behavior is that it depends incredibly upon subtle details of implementations- like the effects of the GC (or lack thereof), how things are laid out in memory, what sort of cache organization you have, what else is going on, are you measuring warm cache or cold cache (i.e. is data already loaded into the cache or not), and so on. Reasoning about cache behavior quickly leads you into a thicket of complicated details, changing any one of which changes the conclusions. For example, I remember a Linux patch several years ago which measurably and significantly increased the performance of Linux simply by rearranging the members of the process structure. But if you're looking at cache effects, I think you're missing the main point. On average, in general, hash tables are going to be faster than trees (although the disparity generally isn't as large as many people imagine). The point I was trying to make was over the cost of "black swan events"- those rare, one in a million events. Consider the following scenario: you have a map that generally has, say, 32 elements in it. If you use a hash table, some set of operations takes, say, 10 milliseconds, but if you use a tree, the same set of operations takes, say, 100 milliseconds. And with such a small number of elements, even if the hash table occasionally takes O(N) time, this likely isn't a noticeable cost- O(32) isn't that big of a deal. So you might consider the hash table implementation is significantly faster. The problem is that when you roll this code out into production, for some weird, unforeseen reason, what is normally 32 elements balloons out to a million elements. Those operations on the tree now take 4x as long. Maybe even 8x as long depending upon the vagaries of cache, comparison costs, etc. So what used to take 100ms now takes 400ms, maybe 800ms. Annoying, but not a serious problem. The hash table based implementation, if you're lucky, doesn't take any longer- the joys of O(1) cost. But if you hit a O(N) corner case, now the hash table is taking 30,000 times as long- and what was 10ms is now 5 minutes. Anon: the problem with including caching behavior is that it depends incredibly upon subtle details of implementations- like the effects of the GC (or lack thereof), how things are laid out in memory, what sort of cache organization you have, what else is going on, are you measuring warm cache or cold cache (i.e. is data already loaded into the cache or not), and so on. Reasoning about cache behavior quickly leads you into a thicket of complicated details, changing any one of which changes the conclusions. For example, I remember a Linux patch several years ago which measurably and significantly increased the performance of Linux simply by rearranging the members of the process structure.

But if you’re looking at cache effects, I think you’re missing the main point. On average, in general, hash tables are going to be faster than trees (although the disparity generally isn’t as large as many people imagine). The point I was trying to make was over the cost of “black swan events”- those rare, one in a million events.

Consider the following scenario: you have a map that generally has, say, 32 elements in it. If you use a hash table, some set of operations takes, say, 10 milliseconds, but if you use a tree, the same set of operations takes, say, 100 milliseconds. And with such a small number of elements, even if the hash table occasionally takes O(N) time, this likely isn’t a noticeable cost- O(32) isn’t that big of a deal. So you might consider the hash table implementation is significantly faster.

The problem is that when you roll this code out into production, for some weird, unforeseen reason, what is normally 32 elements balloons out to a million elements. Those operations on the tree now take 4x as long. Maybe even 8x as long depending upon the vagaries of cache, comparison costs, etc. So what used to take 100ms now takes 400ms, maybe 800ms. Annoying, but not a serious problem. The hash table based implementation, if you’re lucky, doesn’t take any longer- the joys of O(1) cost. But if you hit a O(N) corner case, now the hash table is taking 30,000 times as long- and what was 10ms is now 5 minutes.

]]> By: jrh http://enfranchisedmind.com/blog/posts/problems-with-hash-tables/#comment-37148 jrh Sat, 09 Jan 2010 02:41:49 +0000 http://enfranchisedmind.com/blog/2008/02/25/problems-with-hash-tables/#comment-37148 You are absolutely right! In the real world, I almost always end up with red-black trees over hash maps. There are a few cases where you can tune hash tables because you know exactly what the data will be. But normally, red-black trees are superior in real applications. You are absolutely right! In the real world, I almost always end up with red-black trees over hash maps. There are a few cases where you can tune hash tables because you know exactly what the data will be. But normally, red-black trees are superior in real applications.

]]> By: Anon http://enfranchisedmind.com/blog/posts/problems-with-hash-tables/#comment-37147 Anon Fri, 08 Jan 2010 23:44:45 +0000 http://enfranchisedmind.com/blog/2008/02/25/problems-with-hash-tables/#comment-37147 Very informing for an average programmer like myself, and I would be convinced, but I'm still not sold on the cache miss problem. Obviously you are, and with a lot more experience, so please could you explain further? You've already argued well that code is simpler and better cached with trees, but the problem still remains that the tree itself is not as well localised as hash tables - what is your response to that? Very informing for an average programmer like myself, and I would be convinced, but I’m still not sold on the cache miss problem. Obviously you are, and with a lot more experience, so please could you explain further?

You’ve already argued well that code is simpler and better cached with trees, but the problem still remains that the tree itself is not as well localised as hash tables – what is your response to that?

]]> By: mebigfatguy http://enfranchisedmind.com/blog/posts/problems-with-hash-tables/#comment-37146 mebigfatguy Fri, 08 Jan 2010 23:04:36 +0000 http://enfranchisedmind.com/blog/2008/02/25/problems-with-hash-tables/#comment-37146 I suggest we call an amoritorium on the spelling complaints. I suggest we call an amoritorium on the spelling complaints.

]]> By: Start Using Unordered Map « ASKLDJD http://enfranchisedmind.com/blog/posts/problems-with-hash-tables/#comment-36926 Start Using Unordered Map « ASKLDJD Sat, 10 Oct 2009 16:12:44 +0000 http://enfranchisedmind.com/blog/2008/02/25/problems-with-hash-tables/#comment-36926 [...] Unlike a balanced tree structure, hash table are somewhat unpredictable in nature. If the hash function is poorly suited for the given data set, it would backfire and result in linear runtime. Because of this nasty behavior, some programmers would even avoid hash table altogether. [...] [...] Unlike a balanced tree structure, hash table are somewhat unpredictable in nature. If the hash function is poorly suited for the given data set, it would backfire and result in linear runtime. Because of this nasty behavior, some programmers would even avoid hash table altogether. [...]

]]>