From: Eric Mahurin <eric.mahurin@...>
Date: 2006-07-29T00:09:45+09:00
Subject: Re: converting some autogenerated ruby code to C

On 7/27/06, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
> > One of the next things I want to do in my grammar package is
> > to give it a performance boost by generating C code instead
> > of ruby code. Right now the parsers I generate are a set of a
> > few methods with giant expressions in each.  I would like to
> > try improving the performance by generating and compiling C
> > code instead.  My preference would be to convert my small
> > subset of ruby code to C code (easily have an option to use
> > pure ruby or use ruby/C), but I could also autogenerate C
> > code instead.  Anybody have any opinions/ideas about what
> > approach I whould take?
>
> Couldn't you start with Ruby, see how it performs, and add C support
> later?  Or does it become more difficult later?

I've already have a pure ruby solution.  There are a couple reasons I
would like to have an alternate C solution:

* I'm not using regular expressions at the lowest level.  The solution
I have has a superset of the functionality of regular expressions
(full parsing, works on more than just strings).  I would rather not
move to use regular expressions just for the sake of performance.  I
may still do it at some point, but it will add ugliness since I have
to buffer into a string.  Instead, I would rather just get the same
advantage that regular expressions have - they are written in C.  I'm
not sure if I would be able to quite get to the regex performance or
not.  On one hand, I'm doing code generation/compiling and Regexp is
just putting the regex into a more manageable structure.  On the other
hand, my solution is duck-typed and not tied to String, so I'll have
messaging overhead for each additional char/token/element read
(input.read1next) and checked (pattern.===).

* I would like to get this parsing on par with parsers from other
languages - YACC, ANTLR, etc.  I would like to get some bragging
rights relative to these.  Of course, when you add ruby actions
(blocks) in the parsing this could slow things down quite a bit, since
you're back into ruby instead of C.

> Just remember, not everyone has a C compiler on their system...

That's why I'll provide a pure ruby and a ruby/C solution.

Anybody want to point me to some examples/docs of ruby2c, rb2c, etc?