Niko Schwarz wrote:

> Sure neat program design leads to a good program, but not necessarily to
> more speed or vice versa.
> instead, id say the real performant solutions are generally a bit slower
> than their clean equivalents, but thats another topic.

I have to voice a strong agreement with you.  This is one of the 
difficulties I have with XP and "functional programming" that often seem to 
be ignored.  I've often heard that source documentation is optional; that 
the best way to write good code is to write very small methods and remove 
redundancy, etc., etc.  In my experience, this is good design, but it makes 
for poor code.  For example, in REXML I had some places where I had 
redundant code that was being called in two different situations many 
times.  I tried abstracting the code out and removing the redundancy, but 
this led to a significant decrease in the speed of the processor, because 
of the large additional number of indirects.  The code may have had better 
design, but it was slower.  I often find that with this sort of "good 
design," you tend to get memory bloat, as well.

While I agree with the principle, I disagree with how much many XP folks 
emphasize refactoring (in the sense of removing redundancy).  Perhaps 
someday, when the Ruby interpreter is intelligent enough to inline code 
during execution, this won't be an issue, but for now, when you're trying 
to attain maximum performance, you often have to sacrifice some of the 
design.

--- SER