Hacker News Reader

Comment by pgz | Hacker News Reader

Great article! What I don't understand is why can't they make the compiler inline the function instead inlining manually?

View on HN

This is more than just C function inlining -- the Ruby interpreter, when it does a method call, ends up doing a lot of expensive bookkeeping at runtime to maintain its own internal call stack.

This optimization allows the interpreter to completely bypass a Ruby method call, which is a big win.

I meant having something like:

if (check_cfunc(ci->me, rb_obj_equal)) { return rb_obj_equal(recv, obj); }

and trusting the compiler to inline rb_obj_equal (or using inline), although I reckon you don't probably want rb_obj_equal to always be inlined.

Well inlining this way is an optimisation which the compiler may or may not opt to apply, even after adding inlining hints. By manually inlining it they're introducing a little bit of trivial redundancy but I guess they can be certain there will be no indirect call.

Either that, or they never considered the compiler would most likely inline it.

Oddly enough, they do it for string comparisons: https://www.omniref.com/ruby/2.1.4/files/vm_insnhelper.c#lin...

Oh, sorry...wasn't clear.

The problem with just doing the rb_obj_equal call for everything is that if people override eql? in their Ruby code, you need to call that overridden method, instead.

The consequences of this decision mean that the comparison operator needs to be more complex.

FYI, putting two spaces ahead of each line in a code block will wrap it in a pre-formatted tag. In case you didn't know.

They aren't inlining manually. The optimisation works by making more cases fall into an already existing fast path.

edit: I might have misunderstood - I should say that the patch doesn't do any inlining. The fast path is indeed the manually inlined body of the function.

Reply on news.ycombinator.com