From: SASADA Koichi <ko1@...>
Date: 2015-07-16T12:46:56+09:00
Subject: [ruby-core:69990] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API

On 2015/07/16 4:41, Eric Wong wrote:
> normalperson@yhbt.net wrote:
>> Feature #11339: [PATCH] io.c: avoid kwarg parsing in C API
>> https://bugs.ruby-lang.org/issues/11339
> 
>> Note: I plan to followup commits for other *_nonblock methods
>> Eventually, I even wish to deprecate rb_scan_args :D
>>
>> For what it's worth, I'm more excited about this change than usual
>> and hope to use prelude.rb more.
> 
> ko1/nobu/akr/others: any comments on this?
> 
> My main concern is increased parse time from prelude during startup;
> but we may translate prelude to iseq array and use rb_iseq_load, too.
> The parser seems to be the worst offender for startup performance
> nowadays.

We have some ideas to solve this issue. We discussed about solutions.

Known problems about C-methods parameters:
(P1) slow to parse kwargs with Hash
(P2) difficult to write scan_args
(P3) C-methods can't support Method#parameters

Solutions:

(1) Introduce wrapping Ruby methods into prelude.rb (your idea)
  Pros. Easy to introduce.
        Solves (P1-3).
  Cons. Increase parse time at Ruby launch.

(2) Introduce new API to declare Ruby-like parameters for C-APIs

like: rb_define_method(klass, "xyzzy", klass_xyzzy, -1)

(2-1)
-> rb_defnie_method_??(klass, "xyzzy", klass_xyzzy,
                       "(m1, m2, o1=nil, o2=nil,
                        *r, p1, p2, k1: 1, k2: 2)")

VALUE klass_xyzzy(VALUE self, VALUE m1, VALUE m2, VALUE o1, VALUE o2,
                  VALUE r, VALUE p1, VALUE p2, VALUE k1, VALUE k2)

or
(2-2)
-> rb_defnie_method_??(klass, "xyzzy", klass_xyzzy,
                                       2 /* mandatory num */,
                                       2 /* optional num */,
                                       1 /* rest num */,
                                       2 /* post num */,
                                       2 /* kw num */,
                                       "m1", "m2",
                                       "o1", Qnil, "o2", Qnil,
                                       "r", "p1", "p2",
                                       "k1", Qnil, "k2", Qnil);

(2-3)
-> something = rb_define_method(klass, "xyzzy", klass_xyzzy, 9);
   rb_define_method_argument(something, ...);

(or something like that)

Implementation: Make new rb_iseq only to call C func (klass_xyzzy, in
this case). We have also need several issues.

  Pros. Easy to specify parameters.
        Solves (P1-3).
  Cons. Difficult to design API (it should be compatible in future).
        (2-1) introduces parse time at definition.

(3) Introduce new IDL (Interface Definition Language)

-----
# File klass.??

class Klass
  def xyzzy(m1, m2, o1=nil, o2=nil, *r, p1, p2, k1: 1, k2: 2)
    # This decl. calls C func klass_xyzzy with parameters m1 to k2.
    # We can't write any code here.
  end
end
-----

Translate klass.?? to something like (2).
We don't touch such APIs. No compatibility issues.

  Pros. We don't need to design cool API.
        Solves (P1-P3).
  Cons. Need to design new langauge (IDL).

(4) Introduce new IDL like Ricsin

I made a system calls Ricsin, which enable to embed C code into Ruby code.

http://www.atdot.net/~ko1/activities/ricsin2009_pro.pdf
(sorry, written in Japanese)

----
# File klass.??

class Klass
  def xyzzy(m1, m2, o1=nil, o2=nil, *r, p1, p2, k1: 1, k2: 2)
    # you can write any Ruby code here.
    __C__ %Q{
      /* Given string argument for __C__ is C code. */
      klass_xyzzy(RV(m1), RV(m2), RV(o1), RV(o2),
                  RV(r), RV(p1), RV(p2), RV(k1), RV(k2));
    }
  end
end
----

Compile this file into something C-extension.

  Pros. Easy to write Extensions.
        Easy (and efficient) to write exception handling code
        without rb_protect(). rb_iterate() is same.
        (callback is difficult for C)
        Solves (P1-P3).
  Cons. Allowing everything can make other issues.

--------

Matz likes the middle of (3) and (4) (not allow everything, but allow
restricted). I like (4).

--------

I'm okay to introduce (1) because it is easy and practical.
If we can make (2)-(4), then we can replace from (1) to new mechanism.

BTW, I'm working on making AOT compilation support (it will be continued
to (3) or (4)). Recent rb_iseq_t changes were for this purpose. So that
prelude.rb is nice benchmark for me.

Thanks,
Koichi

-- 
// SASADA Koichi at atdot dot net