On Tue, 2002-11-12 at 11:21, Peter B. West wrote: > 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.
No rule is concrete, I don't think I ever say never :), but having guidelines that say things like: "For published methods it's preferable to return an interface instance as opposed to a concrete class as it allows you to change the internals of the class without breaking external contracts. In short it improves encapsulation", helps a developer make choices. > > 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. Neither did I until a series of code blocks containing the operator came up in the performance tests. The code was compiled with the JDK 1.3.1 for 1.1 compatibility. I'm in no way suggesting not using the operator. It was an example of where you can sometime find performance differences and is a classic example of something that is likely to change with each release of the jvm/compiler (jdk 1.4.1 does produce slightly different opcodes) and something you should NOT optimize out except in extreme circumstances. I love a = b < 1 ? -1 : 1. (oh we did optimize this out, it was in the main paint loop as gave us a 2% overall speed improvement). > "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. I'll disagree, open source can be driven by money, but lets agree to disagree :). We both agree that OS rocks though. > 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] > -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://www.rocketred.com.au/blogs/kevin/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
