3

I'm implementing a key-value store in memory used as a real-time service. It needs to be fast and low latency. Because the number of elements is not known in advance, the table should grow gradually. I prefer open-address hash tables since they are significantly faster than chaining ones. However, open-address hash tables typically require occasional very slow rehashs, during which the service is unavailable. This is not acceptable. On the other hand, extensible hash tables are typically based on chaining, and are slower than open address ones.

Are there any hash tables that are as fast as open address ones (like google's dense_hash_map) and do not have large rehash overhead?

One simple way is to use an array of k small hash tables, so the rehash overhead can be reduced to 1/k. However, this doesn't make sense in my case, because I need to reduce the total unavailable time rather than the max unavailable time. If k small hash tables are used, although the max unavailable time is reduced to 1/k, the rehashs occur k times more often.

user3547691
  • 227
  • 2
  • 9
  • What language are you using? – bhspencer Jun 13 '15 at 17:25
  • The notion of total unavailable time vs. max unavailable time doesn't make sense to me. Extendable hash tables perform the same amount of rehashing work as the regular ones; however the work is split into smaller units and the overhead is amortized across many insert operations. – Nick Zavaritsky Jun 13 '15 at 18:26
  • Do you erase elements? Shrink the table? Keep the load factor in what range? Are keys collision prone given the hash function? Anyway, one option for growth: create an additional, larger table - at least double the buckets - then when inserting new elements in there also take a little extra time to transition one more element from the smaller table to the larger. You'll have emptied the smaller table before needing to expand the larger, and can delete it when that happens. Keep an iterator to next-to-erase in small table so begin/end/insert stay O(1). – Tony Delroy Jun 15 '15 at 12:11
  • maybe you need a `deque>` or something – v.oddou Feb 08 '16 at 01:41

0 Answers0