[infinispan-dev] CHM or CHMv8?

[Dan Berindei]

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 <sanne at infinispan.org>wrote:

> On 25 April 2013 11:51, Galder Zamarreño <galder at redhat.com> wrote:
> >
> > On Apr 22, 2013, at 3:09 PM, Dan Berindei <dan.berindei at gmail.com>
> wrote:
> >
> >>
> >>
> >>
> >> On Mon, Apr 22, 2013 at 2:37 PM, Sanne Grinovero <sanne at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130425/ce959091/attachment.html