commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [collections] MultiKeyMap
Date Sun, 11 Apr 2004 15:30:41 GMT
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.

Interesting.  So you somehow have optimized the comparison operation to 
see if e.g., <key1, key2> "equals" a MultiKey that you have in the KeySet. 
  Does this create a dependency on the internals of MultiKey that we need 
to worry about?

In answer to your original question, I guess I would agree with the "odd 
collections" package placement; though if you look at it the right way 
(take off glasses, so keys merge into a MultiKey) it really is a map ;-) 
In fact, if you limit the interface to just take Object[] arrays as keys, 
it is just a (directly implemented, not decorated) TypedMap.  I assume the 
<key1, key2, key3> stuff here and in MultiKey is also for optimization.

Phil




---------------------------------------------------------------------
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