commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Heuer <heue...@acm.org>
Subject Re: [collections] MultiKeyMap
Date Mon, 12 Apr 2004 03:39:30 GMT

On Sun, 11 Apr 2004, Stephen Colebourne wrote:

> > Why do you we need this when we have MultiKeys available -- i.e., what do
> > you gain by using multiple keys instead of a single MultiKey?  Sorry if I
> > am being dense here, but I don't understand what disaggregation of the
> > MultiKey is buying us.
>
> Me not being clear. To use MultiKey as keys in the map has an overhead. For
> every get/contains/remove you have to create a new MultiKey object which is
> then thrown away once the operation is complete. This was a performance
> hotspot in some recent testing I did.
>
> With MultiKeyMap the get/containsKey/remove operations do not create the
> temporary MultiKey object, they query the data directly. put still creates
> the MultiKey as that is what is actually stored in the hashed map.

Might you also be able to use an unmutable MultiKey for storage in the
hashed map and a mutable MultiKey for lookups, with matching equals and
hashCode implementations?

  void put(Obj a, Obj b, ...) {
    map.put(new MultiKey(a, b, ..));
  }

  private MutableMultiKey lookupKey = new MutableMultiKey();

  Object get(Obj a, Obj b, ...) {
    lookupKey.setKeys(a, b, ..));
    return map.get(lookupKey);
  }

I have something that works this way lying around somewhere.

   michael


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message