5 ms·

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

• timr 12y ago
  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.
  • pgz 12y ago
    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.
    • masklinn 12y ago
      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#line=860 https://www.omniref.com/ruby/2.1.4/files/vm_insnhelper.c#lin...
    • timr 12y ago
      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.
    • saraid216 12y ago
      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.
• gsg 12y ago
  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.