From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2006-07-16T16:22:28+09:00
Subject: Re: How to speed up ruby and make it as fast as possible

Austin Ziegler wrote:
> Performance concerns must *always* be quantified to be addressed. 
There's actually more to it than that, as Zed Shaw pointed out in one of 
his rants a while back. Not only do you have to quantify the performance 
of two alternatives you're comparing, you have to know what the metrics 
mean, how they relate to the economics of the system's users, *and* you 
have to know some statistics. You have to know how to tell when a 
difference in a metric is statistically significant, and you have to 
know what the factors are that affect performance metrics.

> But the C program will typically be harder to maintain.
Maybe ... maybe not. Maintainability more or less equates to readability 
by humans, which more or less equates to documentation and discipline, 
rather than being language-specific. I'm sure you've seen highly 
maintainable C and Ruby code that could only be maintained by its 
author. Certainly the Ruby interpreter is an example of 
highly-maintainable C.

> Since
> you've admitted that you haven't studied CS, you may have missed the
> mantra: beware premature optimisation.
There's an alternative mantra: build performance into your applications, 
just like you build correctness and usability into them. That implies, I 
think, frequent performance unit testing/benchmarking just as it implies 
the other kinds of unit testing. They used to teach people, "make it 
work, then make it pretty, then make it fast." I don't think that advice 
cuts it any more. I think you have to make it work, make it pretty and 
make it fast concurrently.

Of course, as a performance engineer, I get paid to make it fast, so I 
ignore the ugliness and often ignore defects that I know will get fixed 
and don't affect performance. :)