Re: Ruby performanmce improvements

Michael Selig wrote:
> I found 3 main areas which I then focused on:
> 1) rb_call() especially rb_call0()
> 2) Loops & rb_yield(), especially rb_yield_0()
> 3) The large number of recursive calls to rb_eval()

It's perhaps interesting to note I have made similar changes in the past 
for JRuby, and achieved substantial performance gains as a result. More 
below.

> So addressing these one at a time:
> 1) rb_call()
> I found that many of these calls are to CFUNC (internal C) methods such as
> Fixnum#+, most of which are simple, and don't access anything other than
> their parameters. However, in order to execute these methods, ruby is still
> doing quite a bit of work in rb_call0(), such as setting up a stack frame
> etc, which is usually not used. So I made an optimisation that if a CFUNC
> method is being called, and no block is being passed to it, then it bypasses
> stack frame creation. (I also had to make a small hack to "backtrace()" to
> handle errors in this case).

In most of our interpreter objects (stack frames, variable scopes, etc) 
any nontrivial data structures are created lazily. This allows most 
calls to run without creating unnecessary objects. We're doing more and 
more of this, and it's helped a lot each time we make a pass over the code.

> 
> 2) Loops & rb_yield()
> Most of Ruby's loops end up calling rb_yield() for each iteration. However
> much of the work that rb_yield_0 does each time can be often be done once at
> the start of the loop:
>     - Pushing frame, block, vars, class etc
>     - Freeing/creation of dynamic variables (instead they can be initialized
> to NIL each time, unless the context has been saved)
> Also loops done by rb_iterate() (via an IFUNC stub) can be simplified
> further to reduce the overhead of "double-yield".

This one I haven't tried, but it's a great idea. I could modify the 
yield logic in our ThreadContext to do loops natively, likely improving 
the performance of such loops quite a bit. One concern would be making 
sure the looped block doesn't capture additional scope...you'd 
negatively effect the resulting capture, for example, in the following case:

x = 1
numbered_procs = []
loop {
   y = x
   numbered_procs << proc { puts y }
   x = x + 1
}
numbered_procs.each { |p| p.call }

Should print 1 2 3 4, but if each proc was pointing at the same 
containing dynamic vars, it would print 4 4 4 4. Of course I'm not sure 
how Ruby handles capturing these dynamic var scopes as well as I 
understand JRuby.

> 
> 3) rb_eval() calls
> I simply inlined the code for common, simple nodes such as: NODE_LIT,
> NODE_LVAR etc in certain places within rb_eval(), which resulted in a large
> reduction in the number of calls to rb_eval().

I've done a tiny bit of inlining, which has helped. Ruby may also want 
to look at handling simple eval tail-calls by altering local vars and 
jumping back to the top. This reduced JRuby's stack footprint 
substantially and improved performance a measurable amount.

Of course the creation of a bytecode interpreter that doesn't deepen 
stack and performs all evaluation in a single call is better, but that 
will have to wait for YARV. I'm planning to implement a simple YARV 
machine for JRuby soon (a simple version already can run fib()), and 
will report back any performance results I get out of that.

I hope that perf changes like these can get into the 1.8 line. There's a 
lot of low-hanging fruit in Ruby 1.8's current design that could improve 
performance until 2.0 is around.

-- 
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ www.headius.com/rubyspec
[e-mail] -- [e-mail]