From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 454C51960251 for ; Thu, 16 Jul 2015 15:33:07 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 0E231B5D8D2 for ; Thu, 16 Jul 2015 16:01:51 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id D9E0597A844 for ; Thu, 16 Jul 2015 16:01:52 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yzp_Vb3QNdJ for ; Thu, 16 Jul 2015 16:01:52 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id B970F97A842 for ; Thu, 16 Jul 2015 16:01:52 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id B60FF952448 for ; Thu, 16 Jul 2015 16:01:50 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 5CDF5120484; Thu, 16 Jul 2015 16:01:49 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTP id 1ABEC12045D for ; Thu, 16 Jul 2015 16:01:44 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 5F5842038C; Thu, 16 Jul 2015 07:01:42 +0000 (UTC) Date: Thu, 16 Jul 2015 07:01:42 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20150716070142.GA11462@dcvr.yhbt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A72930.40305@atdot.net> X-ML-Name: ruby-core X-Mail-Count: 69995 Subject: [ruby-core:69995] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" SASADA Koichi wrote: > 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 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.