harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: Re: [classlib] TwoKeyHashMap
Date Tue, 25 Jul 2006 05:17:34 GMT
On 25/07/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> In general before we get rid of that class or decide to keep it, I think
> we should work out an approach to performance optimizations.
> It's a rare case when perofmance might be significantly improved for free,
> a regular price is: additional complexity, more code, lack of readability,
> additional memory footprint etc.
> So let's discuss how we approach performance in general and that return to
> this specific class.

Performance in general: premature optimisation is the root of all evil [Knuth]

In this case, we've not only dupllicated logic from a HashMap, but at
the expense of a potential problem that we've not even measured. For
example, there is an assumption that the cost of creating (and
recycling) objects in a wrapper for an equivalent use of a Map is
something that's not even been measured, yet we have code that assumes
that that is a bottleneck.

Is this code even on the critical path? That is, have we profiled this
code to know whether any access is actually directly responsible for
performance problems? If not, then it sounds like assumptions have
been made prior to writing this.

So, we should strive to make code:

1) Correct
2) Easy to understand and maintain
3) Performant
4) Optimised (for memory, speed)

in that order. In this case, I'm not sure whether we've violated 2 in
preference for 4.


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

View raw message