From: Eric Wong Date: 2015-12-28T01:12:42+00:00 Subject: [ruby-core:72532] Re: [Ruby trunk - Feature #11339] [PATCH] io.c: avoid kwarg parsing in C API headius@headius.com wrote: > Eric Wong wrote: > > Using globals or TLS would introduce subtle reentrancy problems > > when calls are nested. I don't want to create more C-APIs > > we need to support long-term, either. > The global would only be used between the runtime making a call with > keyword arguments and the consumption of those arguments for variable > initialization in a C method. There's no nesting of calls, and once > the C method has consumed the values in the global (i.e. immediately > before doing anything else), it is not touched until the next call > with keywords from Ruby to C. The current rb_get_kwargs() calls may be delayed until the keyword is actually needed (to avoid unnecessary hash lookups). Anyways, if somebody can design a good API for internal use, we can use it. Current rb_get_kwargs() and even rb_scan_args() are inefficient and even error-prone: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/68507 > > Fwiw, I like the Rubinius philosophy of using Ruby as much as > > possible a lot and tried to contribute there back in the day. > > Yes, except that this doesn't buy anything because 99% of the logic of > these methods still lives within C code. If you were also moving the > body of these nonblock methods into Ruby, I'd see some value. You've > removed a couple lines of C and added a couple lines of Ruby. And now > there's going to be an extra method in stack traces and an extra Ruby > frame allocated for every call. It's still a work-in-progress, obviously; but the current state already speeds things up for `exception: false' users. Implementation details will change, of course; but we need freedom to change them by having a smaller public C API. Unsubscribe: