> > Or, to put it another way (I don;t recall who said it originally),
> > "It's easier to make a correct program fast than to make a fast
> > program correct."
>
> But neither is easy.  The best thing is to plan for performance and
> correctness from the beginning.  If you don't think carefully
> about the *big* issues relating to performance (I agree that
> "micro" optimization is often misguided), especially
> in the area of careful storage management, I defy anyone to truly
> achieve competitive performance.
>
> .....
>
> The notion that software engineering does not involve
> engineering for performance is definitely specious in
> my view.  In the same way we gag at the thought of "debugging"
> an algorithm into existence, we should gag at the notion of
> "debugging" a program into high performance.

Two topics here: 1. "micro" optimization and 2. *big* issues

1. (micro) When qualified people have designed an architecture to meet the
   requirements and assigned T. J. Hacker to code module X to meet
   requirements Y and Z in 65 milliseconds:  T. J. does not deserve praise
   for doing it in 50 milliseconds if no one (himself included) can
   understand his code.  Even if his code can be understood, he doesn't
   deserve praise for spending 100 hours to code it when a simpler version
   coded in 50 hours would have been rendered just as fast by the
   compiler.  On the first Ada project I worked on, almost every bug I was
   assigned to was fixed by simplifying.  In about half of those cases,
   the extra complexity was an attempt to achieve efficiencies that were
   not required--AND in most of those cases, the simplification speeded up
   the code.

2. (big picture)  For an application that will run _with_others_ on a
   multi-user network, I agree with the comments above.  But for an
   embedded system or a single-user system, I would prefer a
   simple architecture that consumes 75% of the CPU time than a
   complex architecture that consumes 20% of the CPU time.

(But I also agree you don't "debug" a program into high performance.  Even
if performance needs to be improved after coding, re-engineering is often
better than "tweaking.")