tags:

views:

1353

answers:

6

I can't use boost:hash because I have to stick with C and can't use C++.

But, I need to hash a large number (10K to 100k) of tokens strings (5 to 40 bytes length) so that search within those are fastest.

MD5, SHA1 or any long hash function seems too heavy for a simple task, I am not doing cryptography. Plus there is the storage and computing cost.

Therefore my question:

  1. What might be the simplest hash algorithm that will ensure collision prevention in most practical cases.

  2. How many bit to use for the hash value? I am developing for 32 bit systems. Does hash algorithm in Perl/Python use 32 bit hashes too? Or do I have to jump to 64?

  3. Regarding implementation of hash tables in common scripting languages: does the implementation check for collisions or can I avoid that part altogether?

+4  A: 

A general hash function for hash table lookup. It specifies Do NOT use for cryptographic purposes, but since you specified that you have no intent for that then you should be ok.

It Included is A Survey of Hash Functions to try out

TStamper
+6  A: 

1/ Here is a nice overview of the most notable known hash functions.

2/ 32bits should work just fine.

3/ You always need to check for collisions, unless you want to write a funny hashtable :)

arul
You don't need to check for collisions if you don't particularly care about which answer you get. Advantage is that you don't have to store the original key in the hash table so you can save a lot of space.
Zan Lynx
Well, such a non-deterministic behavior is what I meant by 'funny'.
arul
+5  A: 

You can find a good (and fast) hash function, and an interesting read, at http://www.azillionmonkeys.com/qed/hash.html

The only time you should not check for collisions, is if you use a perfect hash -- a good old fashioned lookup table, like gperf.

gnud
I would suggest looking at one that Hsieh's analysis missed: MurmurHash2. http://en.wikipedia.org/wiki/MurmurHash
Steven Sudit
+2  A: 

Have you considered using GLib?
http://library.gnome.org/devel/glib/2.20/glib-Hash-Tables.html

Bastien Léonard
+1  A: 

Try Adler32 for long strings or Murmur2 for short strings.

Adler32 is not a very good hash at all. In fact, it's even worse than CRC-32, as a hash. Murmur2, on the other hand, is a very fast hash with excellent distribution and worst-case behavior, so there's no reason to limit its use to short strings. I don't really understand the basis of your advice.
Steven Sudit
+2  A: 

If you're on a posix alike system and sticking to plain C, I would simply use what the system already has to offer. man 3 hcreate offers you all details or you can find an online version here http://linux.die.net/man/3/hcreate

amo-ej1