2006/7/25, Alex Blewitt <[EMAIL PROTECTED]>:
On 25/07/06, Mikhail Loenko <[EMAIL PROTECTED]> 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]
http://mindprod.com/jgloss/knuth.html
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.
Not sure I agree with your priorities
Thanks,
Mikhail
Alex.
---------------------------------------------------------------------
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]
