[ruby-core:69995] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API

SASADA Koichi <[e-mail]> wrote:
> On 2015/07/16 4:41, Eric Wong wrote:
> > [e-mail] 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

Thank you for response.

> 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.

We cannot avoid parsing Ruby :)  So I want to try to make parsing faster.
Unfortunately, my parser knowledge is not much right now.

> (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)")

OK, I had the same idea like this, too.
But I do not want to introduce a new C API.  IMHO, C API should be
smaller, not bigger.

> (3) Introduce new IDL (Interface Definition Language)

This may be OK... I don't see a big advantage over (1).

> (4) Introduce new IDL like Ricsin
> 
> I made a system calls Ricsin, which enable to embed C code into Ruby code.

I think this is too ugly.  One reason I like Ruby + (limited) C use is
relatively good separation between the different languages.

Working on C-ext is mostly normal C, and not some weird in-between
thing like Perl XS (gross!).  Existing C programmers do not need to
learn a lot of new things to work with current CRuby.

I think it is important that we can use C tools (gdb, ctags, sparse,
etc...) can work without modification.  But I still want to reduce C
and use more Ruby[1].

> I'm okay to introduce (1) because it is easy and practical.

OK, thank you.  I will commit (1) this week and work on more prelude.rb
for other IO/Socket kwargs methods.

> 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.

I want to speed up Ruby parsing + startup in general, too.

Along the lines of AOT: I also consider having something like ccache
(self-managing size, only in $HOME, hashing-based) using rb_iseq_load.

I don't want to pollute users disk with too many compiled files; and it
should use hashing so we may tweak formats/architectures and not worry
about path conflicts with concurrently-installed Ruby versions.

We already have too many bug reports because C-exts/objs get shared.



[1] Fwiw, I like Rubinius philosophy a lot.  However, the non-Free
    contribution platform and eventual implementation
    (slow startup time, "Ruby environment" vs being "another *nix tool"
     which CRuby/Perl are) put me off.