Kevin O'Neill wrote:
<snip/>

So the first recommendation is to use String "+" for this type of
method, it's easier to read and runs faster.

>> [This is from Arved.]

This kind of thing is discussed by Jack Shirazi at length, also.

The thing is, there has long been a blanket instruction, don't use String
concatenation. Programmers learn it by fiat, and never think it through. In
fact, it should be obvious to any programmer (if they are encouraged to
think, that is) that concatenation of literal Strings is not something to
avoid. Assuming a decent compiler.

You've hit the nail on the head. Optimizations are just that
optimizations. They are not "blanket application" things.
Which of course applies to methodological, or "style", optimisations as well. Yes, programmers learn by fiat, and yes, they rarely think it through. For example: always use the interface, not the implementation. Never do early optimisation.

Like anybody else there are times when I optimize as I go, but I really
try and keep in mind, "is this the simplest thing I could do?" Fighting
the urge to apply "optimizations" as you go is hard sometimes but in my
experience leads to a better code base.
I almost always surrender to this urge immediately. As with most urges to which I surrender, I often I regret it afterwards, although nowhere near as frequently as with some of the other urges to which I have been known to surrender.

Despite my occasional regrets, and my occasional unwinding of optimisations which did not work, I know with complete certainty that I expend hugely less energy on my optimisation regrets (which after all represent a minority of cases) than I would if I agonised over every temptation. At the end of the day, I am not ashamed of the code I have written over the years, even though, naturally, I would do much of it differently now.


When you do apply an optimization, prove it's worth. Create a small set
of tests that show the difference and try and run them on a number of
vms.

You'd be surprised at the things I've found, on one embedded vm
x = (y == null) ? a : b;

was 50% slower than

if (y == null)
x = a;
else
x = b;

go figure.
Indeed. I would never dream of writing such a test.
x = (y == null) ? a : b;
is quicker to write than the other, and I like it. Such a difference in performance is highly dependent on the particular compiler implementation, and is subject to radical unannounced variation. I would just write it and get on.

"I like it" is the acid test; for me, of all code, but in particular for open source. Open source may be driven by many things, but money is not one of them. Pleasure is, and is high on the list. In spite of that, OS generates vast amounts of high-quality software. Go figure.

Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to