[ruby-core:82026] Re: [Ruby trunk Feature#13434] better method definition in C API

[e-mail] wrote:
> I wrote the following sentences in hastily so sorry if it has
> English grammar problems.

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

<snip>

> 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 :)

<snip> 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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>