From: Alex Young <alex@...>
Date: 2006-07-17T16:17:45+09:00
Subject: Re: How to speed up ruby and make it as fast as possible

M. Edward (Ed) Borasky wrote:
> Yukihiro Matsumoto wrote:
>> Hi,
>>
>> In message "Re: How to speed up ruby and make it as fast as possible"
>>     on Sun, 16 Jul 2006 18:16:23 +0900, Reggie Mr <buppcpp@yahoo.com> 
>> writes:
>>
>> |My suggestion to anyone new or old that finds Ruby slow is this...
>> |
>> |It will never get better by this group.
>>
>> Agreed.  Saying it's slow is far easier to make it fast.  I know it's
>> slow.  We are working for it.  What can I say more.
>>
>> Blaming, beating, or even insulting us would never help performance.
>>
>>                             matz.
>>
>>
>>   
> One thing that would really help is a "standard Ruby benchmark suite" 
> that one could use to quickly compare alternative implementations. Since 
> it's a little unclear to me what the "target market focus" is for the 
> language, I'll invite the members of this list to post what they think 
> should be in such a suite. Although it's an obvious "answer", I think 
> I'd prefer to leave Rails out of the mix, because Rails performance 
> depends on both a web server and a database directly, and the server OS, 
> client/browser and network bandwidth indirectly.
> 
> So ... what should be in a "standard Ruby benchmark suite?" Does such a 
> thing exist already?
> 
I've never heard of one, but I can't think of anyone better than a 
professional performance consultant to drive one :-)

If they were to be chosen as the focal point for performance 
improvement, the things I'd benefit most from being benchmarked are:

- REXML
- Mechanize
- WEBrick
- Test::Unit

I've pointed out higher-level libraries rather than core because they 
exercise more of Ruby with fewer data points.  Is that the right 
approach?  I realise that one downfall of this perspective is that the 
library authors may have avoided certain techniques precisely because 
they are too slow in the current Ruby implementation, so those 
techniques would be completely sidelined.  Continuations are one that 
instantly spring to mind - I can only find callcc used in one file in 
the stdlib.

An alternative would be to use rubicon's full run time as the benchmark 
- that way we know that all the language features are being flexed, but 
some might get too much weighting.

Thoughts?

-- 
Alex