Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5689
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: FYI performance of hash algorithms |
| Date | 2012-04-23 16:16 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <jn4db2$oht$1@dont-email.me> (permalink) |
| References | <9vlpk9Fd7cU1@mid.uni-berlin.de> |
On 4/23/2012 3:42 PM, M. Strobel wrote: > I am just asking myself which of the many hash algorithms performs best, so I can use > it to index my translation strings. > > So I wrote a test script. It iterates over an array of 3.917.116 strings calculating > the hash of each. > > Here you have the results, with run time, and run time relative to hash length > (smaller is better). > Interesting that the tiger hashes seem to perform well. > > There were only collisions with adler32 (many), crc32 and crc32b. > > /Str. > <snip> Interesting, but only applicable on your system with your libraries and your data. A different system could have different versions of the libraries and completely different performance figures. As for collisions - completely dependent on your data. While you can say some things with certainty (i.e. hashing 2^16+1 values with CRC-16 is guaranteed to have at least one collision), by picking different strings to be hashed your collisions will come out differently. For instance, it's not really surprising that adler32 had a lot of collisions. It was designed for CRC and works better with binary data; it was never meant to be a general purpose hashing algorithm. Rather it was designed for speed. It's also very short. The same is true but to a lesser extent with the CRC-32 and CRC-32b algorithms, so again I'm not surprised about the collisions. But the real question here is - how much does it matter if hashing a string takes 2 microseconds or 2.5 microseconds? Unless you're doing millions of them at one time, no one is going to notice the difference. Personally, when looking at such things I always elect the fewest collisions over the fastest time. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
FYI performance of hash algorithms "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-23 21:42 +0200
Re: FYI performance of hash algorithms Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-23 16:16 -0400
Re: FYI performance of hash algorithms "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-23 22:44 +0200
csiph-web