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 <[email protected]>wrote: > On 25 April 2013 11:51, Galder Zamarreño <[email protected]> wrote: > > > > On Apr 22, 2013, at 3:09 PM, Dan Berindei <[email protected]> > wrote: > > > >> > >> > >> > >> On Mon, Apr 22, 2013 at 2:37 PM, Sanne Grinovero <[email protected]> > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
