benchmarking Perl client hash functions

Greg Whalin
Sun, 18 Jul 2004 11:20:23 -0400

In the Java client, I have the default hashing being String.hashCode() 
as the JVM will keep around a poll of String objects, and thus, it is 
very likely, the hashcode will only need to be computed once for a given 
string.  This is obviously very very fast.  However, I did make sure to 
duplicate the perl hashing method so as to maintain compatibility 
between different clients.  This is a setting that is left up to the end 
user to select when the connection pool (to the memcached servers) is 
instantiated.  I am a big fan of leaving the choice up to the end user. 
  In our install, we do not ever intend on using multiple clients to 
access our cache (in a way where the hashing matters in any rate), so we 
obviously care more about performance and good bucket distribution than 
we do about being compatible with the PHP or Perl clients.  However, 
this certainly may not be the case in other installations, and there a 
choice seems like a very good idea.

Brad Fitzpatrick wrote:

> That could be disasterous if one client has the module and another
> doesn't.  Sets would go one place, deletes another... would get ugly, not
> to mention low hit rates.
> I think if we switch, the thing we switch to should be required, or the
> caller must explicitly choose their hashing scheme (when they provide more
> than one server?).
> - Brad