in reply to Optimisation isn't a dirty word.

I've never seen anyone here rail against optimization per se. But premature optimization is something to be avoided. Consider the classic example: two algorithms, A and B, accomplish some task X. A takes five days to write and is complex and difficult to maintain, but accomplishes X in one second. B takes one day to write, is simple and straightforward, but it takes five seconds to do X.

Which one do you use? The answer, of course, is "it depends." If X is some cronjob that runs once a month, it doesn't really matter if it takes five seconds of background process time, so there's no point in wasting time writing the hard version. On the other hand, if X is some calculation that must be executed thousands of times per day by users who need immediate feedback, then the one-second version is clearly preferred. And finally, how likely is it that X will change? Chances are the inefficient algorithm is more general and the efficient one more fragile.

Optimization is important -- but it's equally important to know when to optimize and to know what to optimize for.