On 18-jan-08, at 12:47, Don Dailey wrote:
I recently read an interesting blog on this, where it was claimed
that
early optimization SHOULD be done when performance is actually a
consideration (and sometimes it isn't.) The idea is that if ignore
performance consideration early, you basically box yourself into a
corner and suddenly it's very painful to fix a performance
problem. The blog seemed fairly balanced to me, he didn't claim
that you should go to herculean efforts to obfuscate your code with
optimizations but that you should always be thinking about
performance,
especially early on when you can do something about it. So I
understand the classical wisdom about early optimization but I believe
there needs to be some balance and I'm open minded on the subject.
Well, my own experience is that it helps a great deal to have
performance in the back of your mind at all times when working on
parts of code that you know are going to be critical when it comes to
speed. But you don't need to do a great deal with it immediately.
Only when there are easy decisions in terms of performance do you
make them. This conforms nicely to the Agile Programming paradigm
that one should never do more than strictly necessary. Don't program
features that are not needed now for some possible future. Because
more often than not that future never comes to pass (or is it past?).
I think this also holds for performance to a great extent.
One other problem with focusing on performance early on is that one
tends to become blind for completely different approaches that are
much more efficient.
Not that I live strictly by this rule. Over the years I have acquired
a large number of programming rules, but the only rule carved in
stone is that no rule is to be carved in stone and that rules are for
those who don't know what they're doing. There! ;-)
Mark
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
