> > 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)
I never advocated optimizing at the expense of the above criteria, we were
discussing optimizations only. I certainly believe a program is a
compromise,
and have often chosen some of those criteria as being more important than
performance savings.
> 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.
Neither did I say that optimizations should be carried out without first
determining whether they're worth it or not. Run benchmarks, optimize what
the benchmark shows to be slow. The point of the discussion was, is it worth
it to save a few microseconds here when milliseconds are being spent there.
My point was, yes it's worth it, every microsecond counts on a busy site.
> 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.
I don't see, provided I have the time and the need (ie my server's resources
are
strained) why I should not, once I have optimized that 20%, turn to the
other 80%
and see what I can do there too.
> - Barrie
>
--
Eric
