# Ruby2CExtension 0.2.0 -- Now with optimizations

**URL:** <https://www.ruby-forum.com/t/ruby2cextension-0-2-0-now-with-optimizations/106836>\
**Category:** Ruby\
**Created:** [June 14, 2007, 2:23pm UTC](https://www.ruby-forum.com/t/ruby2cextension-0-2-0-now-with-optimizations/106836 "2007-06-14T14:23:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dominik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ac91a4/32.png) [@Dominik\_B](https://www.ruby-forum.com/u/Dominik_B)\
**Post date:** [June 14, 2007, 2:23pm UTC](https://www.ruby-forum.com/t/ruby2cextension-0-2-0-now-with-optimizations/106836/1 "2007-06-14T14:23:23Z")

</div>

I am happy to announce the release of Ruby2CExtension 0.2.0.

Ruby2CExtension is a Ruby to C extension translator/compiler. It takes  
any Ruby source file, parses it using Ruby’s builtin parser and then  
translates the abstract syntax tree into “equivalent” C extension code.

More information at [http://ruby2cext.rubyforge.org/](http://ruby2cext.rubyforge.org/).

Ruby2CExtension is available as gem now, so installation is as simple  
as:

gem install ruby2cext

(There is also a setup.rb-release available.)

Ruby2CExtension 0.2.0 supports Ruby 1.8.4 to 1.8.6 (including the  
patchlevel releases).

The two major new features are Eval2C and the new optimizations.

Eval2C allows transparent compilation of Ruby code at runtime. This  
allows to compile (and speedup) code that is generated at runtime. It  
also makes it possible to compile only selected parts of Ruby files.  
This  
feature is similar to RubyInline, but works with Ruby code instead of C  
code.

More information at [http://ruby2cext.rubyforge.org/eval2c.html](http://ruby2cext.rubyforge.org/eval2c.html).

The new optional optimizations can provide speedups for Ruby code by  
sacrificing some compatibility. In particular the optimization of calls  
to (C-implemented) methods of built-in classes can significantly speedup  
Ruby code.

Example:

max = 2000  
z = x = 0  
while (x+=1) \<= max  
y = 0  
while (y+=1) \<= max  
z = (x+y-z) % 32000  
end  
end  
puts z

The compiled version (with all optimizations turned on) of this program  
is about seven times faster than the uncompiled version. This is an  
extreme example, because almost all method calls are optimized, but it  
shows what is possible.

More information at [http://ruby2cext.rubyforge.org/optimizations.html](http://ruby2cext.rubyforge.org/optimizations.html).

Changelog:

- New features:

- Improvements:

- Fixes:

---

<div class="post-metadata">

**Author:** ![Dominik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ac91a4/32.png) [@Dominik\_B](https://www.ruby-forum.com/u/Dominik_B)\
**Post date:** [June 14, 2007, 3:32pm UTC](https://www.ruby-forum.com/t/ruby2cextension-0-2-0-now-with-optimizations/106836/2 "2007-06-14T15:32:35Z")

</div>

On 6/14/07, Dominik B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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