harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: Re: [classlib] TwoKeyHashMap
Date Sun, 23 Jul 2006 21:13:33 GMT
I would definitely agree these sentiments. Optimization, especially of this
kind, should only take place after correct implementation (which I assume we
already have) and significant negative side-effects can be shown. This
mechanism of optimization just increases the amount of code maintenance and
amount of quality assurance. In cases like this, I prefer to lean towards
simplicity.

In any case, there are numerous other approaches to handling the two-key
scenario:
* As Alex and other have mentioned, just use a simple wrapper object with
correct equals/hashCode.
* If you'd rather avoid that object creation, you can use the first key to
link to a embedded Map, where you use the second key to link to the desired
object.
* If the data set is fairly small, like I imagine this is, then you could
just use a two-dimensional array and just do brute force searches. This
could be optimized further by keeping the array sorted and using binary
searches.

-Nathan

> -----Original Message-----
> From: Alex Blewitt [mailto:alex.blewitt@gmail.com]
> Sent: Sunday, July 23, 2006 3:22 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Re: [classlib] TwoKeyHashMap
> 
> I don't think that it makes sense to maintain a completely separate
> data structure just because there's a pair of keys. An object that
> holds two values will do the job just as well, and there should be no
> problem with an object being created, used for a lookup, and then
> recycled in the nursery generation. On the other hand, having a
> separate algorithm is more likely to result in duplicated information
> and maintenance.
> 
> This sounds like premature optimisation to me. After all, how many
> lookups are being performed in the crypto framework? If it's just a
> pairing of (say) provider/hash algorithm, how frequently is it being
> used? Do we have any stats that show the bottleneck is on the access
> of a value from the hashmap?
> 
> Alex.
> 
> On 23/07/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> > It's created for performance optimization. Without it a new object has
> to be
> > created every time a record is seeked in a hashmap.
> >
> > it's used in crypto framework and JSSE provider.
> >
> > Thanks,
> > Mikhail
> >
> > 2006/7/22, Geir Magnusson Jr <geir@pobox.com>:
> > > If it's not being used anywhere, and if no one claims it, +1
> > >
> > > (and if it's being used and can be replaced.... +1)
> > >
> > > Nathan Beyer wrote:
> > > > I'm all for removing it. The last time I looked through that code I
> came to
> > > > the same conclusion your questions infer. If I recall correctly,
> some of the
> > > > actual Map interface methods won't even work correctly if used.
> Also, I
> > > > believe the actual keys were just Strings, so concatenated Strings
> could
> > > > even be used.
> > > >
> > > > -Nathan
> > > >
> > > >> -----Original Message-----
> > > >> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > > >> Sent: Friday, July 21, 2006 11:52 AM
> > > >> To: harmony-dev
> > > >> Subject: [classlib] TwoKeyHashMap
> > > >>
> > > >> Does anyone know why we have a TwoKeyHashMap [1] utility class?
> > > >>
> > > >> I've only looked at it briefly, but I'm left wondering why the
> author
> > > >> chose to write all that rather than use a regular HashMap with an
> object
> > > >> that combines the 'TwoKey's?
> > > >>
> > > >> There may be a subtlety I missed.  Anyone know?
> > > >>
> > > >> [1]
> > > >>
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod
> > > >>
> ules/luni/src/main/java/org/apache/harmony/luni/util/TwoKeyHashMap.java?vi
> > > >> ew=co
> > > >>
> > > >> Regards,
> > > >> Tim
> > > >>
> > > >> --
> > > >>
> > > >> Tim Ellison (t.p.ellison@gmail.com)
> > > >> IBM Java technology centre, UK.
> > > >>
> > > >> -------------------------------------------------------------------
> --
> > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > >> To unsubscribe, e-mail: harmony-dev-
> unsubscribe@incubator.apache.org
> > > >> For additional commands, e-mail: harmony-dev-
> help@incubator.apache.org
> > > >
> > > >
> > > > --------------------------------------------------------------------
> -
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-
> help@incubator.apache.org
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message