From: Eric Mahurin <eric.mahurin@...>
Date: 2007-06-14T22:31:18+09:00
Subject: Re: [ANN] Ruby2CExtension 0.2.0 -- Now with optimizations

On 6/14/07, Dominik Bathon <dbatml@gmx.de> wrote:
> I am happy to announce the release of Ruby2CExtension 0.2.0.
...
> The two major new features are Eval2C and the new optimizations.

Thanks Dominik!

I'd like to point out that Dominik's Ruby2CExtension is generates C
code that does the same as the original ruby code 99% of the time.  As
long as your code isn't doing things too crazy (like overriding the
built-in class methods), it should work.  The way I see it, the next
step could be a full-fledged ruby compiler.

I've used this with my grammar package (which I need to re-release) to
generate parsers that were 4-6 times faster.  To get the best
optimizations though, I had to generate the ruby code a certain way.
I use the Eval2C as an eval replacement on the generated lexer/parser.

Dominik, have you done any profiling (with gprof or something else) to
see where the majority of remaining time is being spent on a fully
compiled piece of code?  I think the major components would be:
Ruby2CExtension code, other C implemented methods (i.e. built-in), and
method lookup/calling code.  I'd expect the majority of time to
typically be in the method lookup/calling code.  If so, you may want
to ask Matz/ruby-core/ruby-dev to provide some way to just lookup a
method so that the calling overhead using this info would be minimal.
This would be useful where you detect a that an object calls a method
multiple times.  Better yet, it could be applied to a variable and
re-lookup the method only when the class changes.  Like many other
optimizations, this would sacrifice some compatibility - can't change
a method (including in a meta-class) after you start using it.

Thanks again for the great package!

Eric