Yeah, I don't think you could extract the hash from the "cache of hashes" without computing the hash in the first place...
My idea was to wrap the key in a KeyWithHash object and cache the hash there (since we're looking up the same key in a lot of maps during a single invocation). Sorry Galder, I forgot about your patch, but I still think we'd need a wrapper for keys in order to cache the hash code even if we could define an Equivalence function. On Thu, Apr 25, 2013 at 2:27 PM, Sanne Grinovero <sa...@infinispan.org>wrote: > On 25 April 2013 11:51, Galder Zamarreño <gal...@redhat.com> wrote: > > > > On Apr 22, 2013, at 3:09 PM, Dan Berindei <dan.berin...@gmail.com> > wrote: > > > >> > >> > >> > >> On Mon, Apr 22, 2013 at 2:37 PM, Sanne Grinovero <sa...@infinispan.org> > wrote: > >> We also have been toying with the idea to hash each key only once, > >> instead of both with the consistent hash (to assign the node owner) > >> and once in the CHM backing the datacontainer. > >> I doubt we need the datacontainer to implement Map at all, but at > >> least if we go this way we don't want the hash to be affected by the > >> VM instance or different nodes won't agree on the expected owner ;-) > >> > >> > >> For consistent hashing it would probably be better to cache the hash > after applying MurmurHash to it anyway. So we could in theory hack our > CHMV8 to use a cached hash code computed with MurmurHash and a > cluster-specific salt. > > > > ^ Rather than hacking CHMv8, better to provide an Equivalence function > (which CHMv8 will have an instance variable of) for the keys which keeps > the cache of hashes or something… once that work is committed, we can > discuss further :) > > +1 to use your cool implementation. Don't like too much the sound of > "cache the hashes or something", I didn't actually look at the code, > but from gut feeling I would hope the Equivalence function to be > stateless? We might be able to pass the to-be-reused hash as a > parameter in primitive form. > > Sanne > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev