String hashing was: Thou shalt have no other gods before the ANSI C standard 1544

difference. The other way just seemed easier to describe for others and was potentially less invasive to what CBF posted.

I didn't go in search of collisions, I just picked a random medium length strength and saw a less than ideal pattern emerging and stopped there. That's why I was surprised at the comments from DJB indicating that it was good at not producing collisions and "extremely fast" as well. It doesn't appear to do either of those things for reasonably long strings. It's only marginally faster than CRC32 on my system, and considerably slower than BobJenkins or SFH.

As an aside, FNV isn't exactly showing its legs here, although to be fair Noll's website has several different implementations than what you use in the test code with various optimization tricks. I haven't tried putting those versions in to see what they do yet.

Suffice it to say, unless some find a similar flaw in SFH, it seems very promising, and quite a bit faster in the bargain. I'd like to try it with random strings of various lengths instead of just doing the same hash over and over and see how that plays out.

I have a particular application in mind where this might be a huge win, I'm going to try that also, but it will be a lot more difficult to measure accurately, apart from seat of the pants testing as opposed to this instrumented test fixture.

Agreed. It looks very promising.

-- Randy Howard (2reply remove FOOBAR) "Making it hard to do stupid things often makes it hard to do smart ones too." -- Andrew Koenig