Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates
 64.233.182.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=k4jU5ESQU1+ty/PXDSB/6SyRELFbqRl20noDVOqWlnlUsO3NXdfG1BsaoDoZoXY7gW87l9H0Av3lJC2fphHfI55AW06SW6YJjQ+WRBDtuLzmK9E3zA11Ro19yT+/R/R3BuV+mL+6usEh+ONPpC7/T6W1/DQybhnOYmwflvgXiqc=
Message-ID: <906dd82e0607250032t42cace5bn84745a3114d674c7@mail.gmail.com>
Date: Tue, 25 Jul 2006 14:32:46 +0700
From: "Mikhail Loenko" <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Re: Re: [classlib] TwoKeyHashMap
In-Reply-To: <636fd28e0607242217t3f11b3ben8f223b61a1239806@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <636fd28e0607230122ic1c5087p392275a7c26a64de@mail.gmail.com>
	 <000c01c6ae9c$dc976b80$0f01a8c0@LITTLEGUY>
	 <ddda44ee0607240925hf56c8cbh8e8ceb1c02d3e482@mail.gmail.com>
	 <906dd82e0607241800i4beff83cs2294308969904911@mail.gmail.com>
	 <636fd28e0607242217t3f11b3ben8f223b61a1239806@mail.gmail.com>

2006/7/25, Alex Blewitt <alex.blewitt@gmail.com>:
> 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]
> 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: 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