On Aug 02, 2006, at 18:03 UTC, Brendan Murphy wrote: > > That's not mentioned because, in general, it is patently untrue. > > Quite the opposite: speed-optimised code is usually longer, more > > complex, and far more obtuse than unoptimised code. > > > > Code that's short, clean, and efficient doesn't count as optimised > > code; that's just good code. We all write that way whenever we > > can. But serious optimization will require much more complex > > tricks, like loop reordering for data locality, changing to a more > > complex (but efficient) algorithm, etc. > > Like Theo's statement, your statement is just as incorrect in the > opposite direction. Your assumption that there exists a linear > relationship between code complexity and the state of optimization > is false.
I make no such assumption, and you've set up a straw man -- an incorrect statement which is not, in fact, what I was saying. See the key phrases "in general" and "usually" in my statements above. I stand by my statement that highly optimised code is usually (and in general) longer and more complex than unoptimised (but well-written) code, both from my own experience and because I've closely followed the work of my spouse, who is a computer scientist who specializes in advanced optimization (and the very difficult problem of having a compiler do things like managing data locality for you). But *of course* your strawman about a linear relationship between code complexity and optimization is false. Of course one could write complex code that performs poorly. > People who create maintainable code are far more likely to > write optimized code! People who are sloppy in writing their code > are more likely to not write optimized code since their code is > more difficult to manipulate. Well, I'm sure that's true too. But when the people who create good maintainable code find a need to optimize it, usually maintainability is reduced. Example: a Mandlebrot program in RB was first written using a nice neat complex number class. Profiling and optimization led to eliminating that class and inlining all the calculations, resulting in a dramatic speedup but more complex, less general, and harder-to-maintain code. Short, maintainable code, and optimization for speed, are orthogonal aspects -- but still incompatible, in most cases. Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] Verified Express, LLC "Making the Internet a Better Place" http://www.verex.com/ _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
