benchmarking Perl client hash functions

[Anatoly Vorobey]

On Mon, Jul 19, 2004 at 03:25:47PM -0400, Larry Leszczynski wrote:
> 
> On Mon, 19 Jul 2004, Anatoly Vorobey wrote:
> 
> > If crc32 is better _and_ faster than the current Perl hashfunc, let's
> > throw the current Perl hashfunc away altogether. There's no good reason
> > to enshrine it, it was just a quick hack.
> 
> Could just replace the exiting _hashfunc with the crc32 version, but how
> do you guys feel about introducing the dependency on String::CRC32?  If
> that's a concern, how about making crc32 the default, but allowing an
> option to explicitly turn it off and use the existing algorithm if for
> whatever reason you can't install String::CRC32?

Since String::CRC32 seems small and well-maintained, I personally don't 
mind including this dependency (Brad?). What I'd rather have us wait 
for before finalizing such a decision, however, is some more benchmarking 
data confirming what has already been posted about the benefits of CRC32 
vs. the current function. 

Perhaps if String::CRC32 is not present, the Perl client could require 
the caller to supply their own hashfunc, rather than use the current 
one. That seems a cleaner approach, if indeed String::CRC32 is so much 
better, and given that it seems easy to install. 

-- 
avva
"There's nothing simply good, nor ill alone" -- John Donne