Eric Cholet wrote:
> 
> These
> things add up, so don't you think that whatever can be optimized, should ?

Wrong question, IMHO: it's what you optimize for that counts.  Several things
come to mind that are often more important than performance and often mean not
optimizing for performance (these are interrelated, of course):

  Stability / reliability
  Maintainability
  Development time
  Memory usage
  Clarity of design (API, data structures, etc)

There's a related rule of thumb that says don't optimize until you can test it
to see what the slow parts are.  Humans are pretty bad at predicting where the
bottlenecks are.

I think of it this way: if your process spends 80% of it's time in 20% of your
code, then you should only be thinking of performance optimizing that 20%, and
then only if you identify a problem there.  Of course, there are critical sections
that may need to operate lightening quick, but they're pretty few and far between
outside of real-time, embedded, or kernel hacking.

- Barrie

Reply via email to