Hello Scott, SR> Michael Neumann wrote: >> Nospam wrote: >> >>> Hi, >>> >>> Once in a while the question pops up if it is possible to compile Ruby >>> code to native machine code. The answer has always been no. But I keep >>> wondering how hard it would really be to make this possible. >>> >>> Ruby is written in C. And when Ruby parses a Ruby script it converts >>> each statement to a C call. Probably the same calls you can use on >>> your own in a Ruby C extension. So why wouldn't it be possible to >>> parse a Ruby script and convert all statements to Ruby C code and put >>> it in a *.c file (instead of calling the Ruby C statements directly). >>> This *.c file can then be compiled into machine code with a C compiler >>> like gcc. If each *.rb file is converted to a C file it could be >>> compiled to a dynamically loadable library which could then be used on >>> require statements (just like regular Ruby C extensions). >>> >>> What I mean is, this... >>> >>> class Example >>> def example >>> puts "Hello World!" >>> end >>> end >>> >>> .... can also be written in C using the Ruby C API, am I right? So why >>> wouldn't it be possible to convert all Ruby code to C code using the >>> Ruby C API? >>> >>> This would probably result in some performance gain (no need to parse >>> the code anymore at run-time), but for some people more important, you >>> can distribute your Ruby applications closed-source. In the future the >>> performance gain maybe could be increased by performing special >>> optimizations during the conversion process. >> >> >> I remember that a long time ago, there was a ruby-to-c compiler (was it >> called r2c?). But IIRC, there was only little performance gain. Remember >> that you still need a Ruby parser, due to "eval". It would be nice, but >> I'd even more like to see a bytecode compiler (written in pure Ruby >> running on top of the bytecode interpreter). >> >> Regards, >> >> Michael >> >> SR> Yes, I have to vote for a bytecode compiler. Right now I'm using ruby SR> to develop some software on an embedded arm-linux device. I've found SR> that for this application, which is not very demanding of the system, SR> that ruby can perform pretty comparably to an equivalent C program. And SR> the development time it saves to write in a higher level language is SR> worth its weight in gold. But every time I run a ruby program it takes SR> it a significant and noticable amount of time to start up. This is SR> obviously due to the ruby parser compiling the text into bytecode every SR> time. If it was possible to precompile this bytecode and put that on the SR> target machine it would have significant advantages. Also, it would make SR> it possible to distribute the application without distributing the SR> source code to it. That isn't so important for us, but it may be for SR> others. Use ExErb, in version 3.2 it stores the node trees. So this is true anymore. But from my experience i'm not sure if parsing is the time killer. I think it is building up the whole method universe, filling the method lookup caches and do other housekeepings. If you want to check this, do a "cat * > out.rb" and feed the huge "out.rb" into the "yy_compile" function, which only generates a node tree but not does the method building. -- Best regards, emailto: scholz at scriptolutions dot com Lothar Scholz http://www.ruby-ide.com CTO Scriptolutions Ruby, PHP, Python IDE 's