Eric Mahurin
7/28/2006 3:10:00 PM
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?