On Mon, 2012-01-09 at 13:49 -0500, Stephen Gallagher wrote: > > > > > On Tue, 2012-01-03 at 18:00 -0500, Simo Sorce wrote: > > > > > > >From [PATCH 0/0] A shared memory cache to perform better: > > > > > > > > I have one other question about this patch. Would you mind identifying > why you chose to go with the murmurhash3 algorithm instead of expanding > dhash to expose its hash function publicly?
Yeah a few reasons: - The algorithm in dhash was difficult to isolate in the code - The dhash algorithm is tailored to handle tables that can be expanded or reduced. We can't change the hash table size live as it would make the client quite complex, so it wasn't a great match. (apologize if I misunderstood something fundamental). - I couldn't find out how good the algorithm in dhash was, so I looked for what pass by the best algorithm today, and murmuhash3 seem to have the best collision rate among known non-cryptographic fast-hash functions. - Using the dhash hash function would have required isolating it and building it as a static library, because I do not want to add a library dependency to sss_nss (our goal is to always keep clients as contained as possible). - This function is basically part of the ABI contract between the client and the server side of sssd, and I didn't want to constrain dhash to change the algorithm to a different one if that was required for whatever reason. By keeping the 2 implementations unrelated dhash can be changed at will without fearing consequences on the sssd client/server ABI. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel