In my opinion optimization is removing reduntant operations. In my experience, removing reduntant operatations tends to make code smaller and cleaner, as well as faster.

Of course, premature optimization is always bad. However, early optimization isn''t always bad. It would probably be benefitial if that distinction was made more often in discussions on this topic. Choosing a faster algorithm over a slower is optimization as well, as I see it.

Optimization is part of both the design and coding phase. Of course, optimizations in the design needs to be done before you can run a profiler on the realization of that design.

An argument for early (design/code) optimization is what consequences later optimization may have. In an ideal world, everything would be in magical black boxes, but often, optimizing a piece of code do change how other code communicate with it, and so the changes propagate throughout the project.

I am all for: make it work, make it robust, make it fast, in that order. But, if speed is any concern at all, you will need to take it into consideration early, so you don''t have to break, or rewrite large portions of, code when optimizing later. I do usually build one-to-throw-away, in which optimization (that require effort or lessen readability) is banned. Because of this, it is usually easier to actually throw it away.

quote:Original post by civguy

quote:Original post by CWizard
In my opinion optimization is removing reduntant operations. In my experience, removing reduntant operatations tends to make code smaller and cleaner, as well as faster.

That''s simply a wrong definition for optimization. Often optimizations make the code more obfuscated, harder to maintain and longer. There are some trivial optimizations that come from removing redundant operations, but those don''t even make the program run much faster as the compiler may be smart enough to skip some of the useless calculations.

Actually, I think that is the exact definition of optimization (as it relates to computation). Do you think that optimizing an algorithm means making it perform more operations?

quote:Original post by civguy
It can do more, but less costly operations as well. Or you can make your program more cache friendly, sometimes by increasing operation count. It''s only about speed, not operation count.

Admittedly, it is quite complex on todays computers, but in theory it still stands; it is to perform as little work as possible (including doing cache misses etc).

Consider mathematical formulas. I am very bad a coming up with examples (which I''ll be demonstrating shortly ), but take how we calculate an alpha value. (s = source, t = target, a = alpha, r = result):

r = s(1 - a) + t * a;
r = s - sa + t * a;
r = s - a(s + t);

The latter is what we''d use; it is more compact and has fewer and cheaper operations. The same sort of optimization can be applied to normal code as well; making it shorter, cleaner, more compact, and fewer points of errors.