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.]
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.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.
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.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.
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 setIndeed. I would never dream of writing such a test.
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.
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]
