[H-GEN] Which is better?

Russell Stuart russell at stuart.id.au
Wed Apr 28 00:48:46 EDT 2004


On Wed, 2004-04-28 at 14:14, Adrian Sutton wrote:
> Yes, that's my entire point.  You can't prove this stuff, you can't say 
> that this minor tweak improves performance by X amount, you can't say 
> anything definitive about performance until you profile the real world 
> application you're dealing with.  To prove my point all I need to do is 
> cast some doubt on the authoritativeness of your figures, which I did.  
> I presented a number of things which may have affected the results you 
> got.  You've come back and disagreed with some of them and thrown some 
> more numbers into the mix that you believe support your case, some 
> right, some wrong.   At this point though there is no point in us 
> continuing to go back and forward over this.  If you want to believe 
> that ++i is faster than i++ and that it's worth your while remembering 
> that, go right ahead.  I'll happily continue with the process that has 
> proven itself time and time again in my work with Java:

You imply I said that Harry should change ++i to i++, or something.  I
didn't actually say that.  What I said was Harry: if you want to
optimise your Java, try to reduce your memory allocations /
deallocations.  For example, it probably isn't worth the effort to pause
for a few seconds, and check if a statement like "i = j;" can be moved
out of the loop, but it is worth you while to consider moving "i = new
I();" out of a loop.  Or perhaps consider making the class "I" immutable
so you don't have to make defensive copies.

Both you and Andrae then disagreed with that statement, aggressively.  I
am still not sure why.  For the record, I originally said that Harry's
original optimisation wasn't worth doing.  Still, it was interesting to
investigate it, if for no other reason than to see if my gut feeling was
right.  It turned out that under 1.5.0 it was a total waste of time. 
Under 1.4.1 your mileage may vary.

> 1. Think through your design and choose appropriate algorithms.
> 2. Write clean maintainable code.
> 3. If the application isn't fast enough, profile it.
> 4. Fix the performance bottle necks.
> 5. Go to step 3.

A fine recommendation, and I don't recall anyone arguing against it when
others said similar things in this thread.  Exactly what constitutes
"clean maintainable code" is possibly the real subject of this debate.






More information about the General mailing list