From: Eric Wong Date: 2017-07-13T07:36:13+00:00 Subject: [ruby-core:82026] Re: [Ruby trunk Feature#13434] better method definition in C API ko1@atdot.net wrote: > I wrote the following sentences in hastily so sorry if it has > English grammar problems. no problem. > normalperson (Eric Wong) wrote: > > Yes, that would be great. However, we will take into account > > fork and CoW savings. > > Maybe this table will be read-only table so that no CoW issue. OK. > > Should I try to implement your table idea? Or did you already > > start? You are more familiar with this, but maybe I can try... > > Sure. But we need to consider the strategy about this issue. > Note that lazy table loading is common with the following approach S1 and S2. Sidenote: Unfortunately, I don't think I can start a major new feature at this time. My situation is different than 2 weeks ago. I will of course continue to support/improve existing proposals like [Feature #13618] (auto-Fiber), but I will probably focus smaller changes instead of big ones. > (Strategy-1) Define a table in C and use it. > There are no jump from current implementation. But not so much fruits. Right. > (Strategy-2: S2) Use ISeq binaries also for C methods. OK, I like this :) all good, no comments. > * Current ISeq binary dumper is not space efficient (dumped > iseq is huge because I don't use any compression techniques). > Of course we can improve it (but we need to care about loading > time). For loading time, smaller binary dump means less I/O and maybe less allocations. This is more noticeable for people on rotational disks. I also think iseq can be compressed by sharing repeated method/constant lookups: File.unlink(f) if File.exist?(f) or: str.gsub!(pat1, rep1) str.gsub!(pat2, rep2) str.gsub!(pat3, rep3) Ideally, that is only one method lookup and cache for #gsub, not 3 lookups + 3 entries. Of course, we will need to detect/annotate those methods and operands have no side effects which can expire caches. > > In addition to improved kwarg handling for C methods, my other > > goal is to be able to mark read-only/use-once/const/etc. args to > > avoid unnecessary allocations at runtime. This will be more > > flexible than current optimizations (opt_aref_with, opt_aset_with, etc). > > Sure. That is also my goal in long time (build a knowledge database of C-implemented behavior). With chatting with nobu, we consider several notation. > > ``` > class String > > # @pure func <- comment notation > def to_s > C.attr :pure # <- method notation it doesn't affect run-time behavior. > self > end I prefer method notation since it is less likely to conflict (RubyVM::C, not 'C' :) Comments might conflict with documentation. > # rep: ... <- comment notation > def gsub(pat, rep = nil) > C.attr(rep: %i(const dont_escape)) # <- method notation > C.call :str_gsub(pat, rep) > # or (*1) > if rep > C.call :str_gsub_with_repl(pat, repl) > else > C.call :str_gsub_with_block(pat) > end > end > end > ``` Anyways, I like this S2 since it still looks like Ruby :) > *1: For performance, we may need to introduce special form to > branch by arguments. But it should be only performance > critical case, such as `Array#[]`. OK. Unsubscribe: