From: Markus Schirp <mbj@...>
Date: 2007-09-28T02:16:20+09:00
Subject: Re: question on bottleneck of ruby

On Fri, 28 Sep 2007 01:59:36 +0900
"Richard Conroy" <richard.conroy@gmail.com> wrote:

> On 9/27/07, Roger Pack <rogerpack2005@gmail.com> wrote:
> > Thanks Kirk.
> >
> > Follow-up question: it seems like there have been a lot of
> > 'replacement attempts' of the Ruby interpreter, but none of them
> > seem to have really really sped it up (jruby, rubinius, etc.)
> 
> I don't think that the developers of the alternatives would consider
> themselves as 'replacements' or 'competitors'. With the possible
> exception of Rubinius. But that's its intent - to be the replacement
> MRI for Ruby 2.0; in the meantime YARV (1.9) is the Ruby Interpreter
> based on the current code base. There have been a number of synthetic
> benchmarks that show interesting performance improvements in YARV
> currently. I am not sure how it stacks up in real world use though.
> (Not being critical here, real-world benchmarks are notoriously
> difficult to do right).
> 
> > Does this mean that they suffer from the same bottlenecks?  Is Ruby
> > just a hard language to optimize for?  Do they all tree walk and
> > have slow method dispatch and a slow GC or something?  Hmm.
> 
> You should definitely keep up to date with the JRuby guy's blogs (Ola
> Bini and Charles Oliver Nutter). They have been quite detailed on
> this topic over the last few months. While their solutions for
> performance are to make JRuby very compatible with the JVM, they
> articulate the particular reasons for Ruby's weak performance.
> 
> Basically, Ruby is hard to optimise for. It's super dynamic nature
> (Open Classes) mean that traditional compiler/interpreter tricks
> cannot be used.
> 

So why not add a "class freeze method", so that these traditional
compiler/interpreter tricks can be used? 

During development you just not activate this "frozen class state", for
releases you can freeze some "performance penalty" classes.
So we not loose ruby's super-dynamic character (during development),
and got the benefits from more agressive optimisations.