From: Robert Feldt <feldt@...>
Date: 2001-11-09T09:29:17+09:00
Subject: [ruby-talk:24716] Re: Why is ruby slow (compared to perl)

On Fri, 9 Nov 2001, Sean Russell wrote:

> > Just so that I'm following: You're assuming that the only/most important
> > quality criteria of code is its speed of execution, right?
> 
> No, I'm assuming that in some cases, the most important criteria of code is 
> the speed of execution.  Furthermore, I'm rebelling against the trend I see 
> to completely ignore issues such as speed.  I'm hyper-sensitive, I suppose, 
> because I've been coding exclusively in Java for the past 7 years, and I've 
> seen what a difference speed can make in the general acceptance of any 
> software.  The most beautiful, functional code is absolutely worthless if 
> it isn't used because it is too slow.  On the other hand, fast code will 
> tend to be used even if it is really, really.  In the end, the users (whom 
> we're writing the software for) don't care what the code looks like; they 
> just want it to work right and run fast.
> 
I think we basically agree. BTW, I like rebellion so keep up the good
spirit! ;-)

You're right that we shouldn't turn our focus from one "silver bullet" to
the next and forgetting about the multi-objective quality landscape we're
traversing in search for a good-enough hill to settle on for the project
at hand.

> maintainable.  However, code speed is almost never stressed by XP 
> advocates, who tend to stress "never break the rules".
> 
Funny enough my impression of XP is more like "here are some cool
rule-breakers that kind-of worked for us". I probably misread them and
jumped to conclusions. I tend to do that... ;-)

> > If you're trying to attain maximum performance then why use Ruby? Sure,
> > advance in VM's might take Ruby down to 2 times C (although I doubt
> 
> Of course I want my software to be as fast as possible, given the 
> environment I've chosen to work in.  There are no absolutes; in any 
> environment, there's fast enough, and not fast enough.  Often, the line 
> between the two is very narrow.  Even in C, there are cases when you want 
> to optimize for speed.  This is why we choose quick sort over bubble sort.  
> Quick sort is a more complicated algorithm, but the advantages of its speed 
> outweigh the advantages of having "pretty code."  Wouldn't you agree?
> 
I agree.

> > I'd think that if you have a good design, profile, attack the
> > bottlenecks and maybe even lift some of it to C then you'll be better off
> > than with a poorer design.
> 
> True.  I agree with you completely.  XP, however, insists that you 
> refactor, refactor, refactor, and remove all possible redundancies.  
> Sometimes the way to improve speed and remove bottlenecks is to inline some 
> code.
> 
Yes. However, often I find the most dramatic speed improvements come from
checking if all the things done are necessary, if the algorithms used have
"good" (algorithmic) complexity and wallclock timing properties, which
data structures have been chosen and how this affects the algorithms. For
Ruby its also important to use built-in methods. Further along down the
list is to create few objects. "Manually" inlining stuff is not
high on this list. However, when its needed I think its better done after
the performance problem is real and not as a "premature
optimization". But, then again, who can make absolute statements about an
ever changing world. Lets just expand our bag of
tools/patterns/methods/ideas...

Anyway, I think we basically agree. And I'm a recent convert myself... ;-)

/Robert