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:[EMAIL PROTECTED] > Sent: Sunday, July 23, 2006 3:22 AM > To: [email protected] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > 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:[EMAIL PROTECTED] > > > >> 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 ([EMAIL PROTECTED]) > > > >> IBM Java technology centre, UK. > > > >> > > > >> ------------------------------------------------------------------- > -- > > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > > >> To unsubscribe, e-mail: harmony-dev- > [EMAIL PROTECTED] > > > >> For additional commands, e-mail: harmony-dev- > [EMAIL PROTECTED] > > > > > > > > > > > > -------------------------------------------------------------------- > - > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: harmony-dev- > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
