Issue #16188 has been updated by jeremyevans0 (Jeremy Evans).


Eregon (Benoit Daloze) wrote:
> jeremyevans0 (Jeremy Evans) wrote:
> > There are a ton of other changes in 2.7 that could affect performance besides `ruby2_keywords`.
> 
> Any specific guess?

After discussion with you and @mame , it appears my benchmarking was flawed and the performance difference is closer to your measurements.

> Your original diff kept quite a lot more complicated code in `setup_parameters_complex`, so I think that diff is already more precise and seems to show an higher overhead (see my previous comment).

Actually, the only relevant difference is the same in both your and my removal diffs, the code in CALLER_SETUP_ARG, not the code in `setup_parameters_complex`.

> > So a 10% performance difference would be 0.1-1% difference in a real world benchmark.
> 
> Still, if there are `foo(*args)` calls in a performance-sensitive part of a real world benchmark I'd expect it can be noticeable.

Possibly.  A real world benchmark would be beneficial to determine that.

> > Well, we could guess, or you could pick an existing real world benchmark and run it and report the results for:
> 
> OptCarrot might be affected, it uses `send(*DISPATCH[@opcode])` in the main loop of the CPU:
> https://github.com/mame/optcarrot/blob/ded9d9379324d968867d1e052dbbc811d45afd4d/lib/optcarrot/cpu.rb#L939
> However the CPU is only a small part compared to the PPU in OptCarrot.

OptCarrot would be a good choice for a real world benchmark for this.

> > Do all non-`ruby2_keywords` tests still pass with that?  If so, what are the benchmark results with the patch?
> 
> I'd think so, I just manually removed dead code based on RHASH_PASS_AS_KEYWORDS never happening.

From your later testing, all tests pass, so your removal diff appears correct.

> > > Can you give an example the above approach (capturing the call inside the lambda) cannot handle?
> > 
> > No.  Certainly there is a way to always move code into the lexical scope.  It is a more difficult change and it makes the resulting code harder to understand, but it is possible.
> 
> I think it's only more difficult in rather rare cases, and it makes it significantly easier to understand and use than `ruby2_keywords`.

It is always more difficult to move code compared to not moving code.  How much more difficult depends on the situation.

The discussion of lexical `pass_keywords` is academic anyway without a proposed plan/diff for implementing it.  Your proposal only works if you can move code into blocks in the lexical scope, and `pass_keywords` as implemented in a previous pull request did not support that.

----------------------------------------
Misc #16188: What are the performance implications of the new keyword arguments in 2.7 and 3.0?
https://bugs.ruby-lang.org/issues/16188#change-82824

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: jeremyevans0 (Jeremy Evans)
----------------------------------------
In #14183, keyword arguments became further separated from positional arguments.

Contrary to the original design though, keyword and positional arguments are not fully separated for methods not accepting keyword arguments.
Example: `foo(key: :value)` will `def foo(hash)` will pass a positional argument.
This is of course better for compatibility, but I wonder what are the performance implications.

The block argument is completely separate in all versions, so no need to concern ourselves about that.

In Ruby <= 2.6:
* The caller never needs to know about the callee's arguments, it can just take all arguments and pass them as an array.
  The last argument might be used to extract keyword, but this is all done at the callee side.
* Splitting kwargs composed of Symbol and non-Symbol keys can be fairly expensive, but it is a rare occurrence.
  If inlining the callee and kwargs are all passed as a literal Hash at the call site, there shouldn't be any overhead compared to positional arguments once JIT'ed.

In Ruby 2.7:
* The caller needs to pass positional and keyword arguments separately, at least when calling a method accepting kwargs.
  But, if it calls a methods not accepting kwargs, then the "kwargs" (e.g. `foo(key: :value)`) should be treated just like a final Hash positional argument.
* (If we had complete separation, then we could always pass positional and keyword arguments separately, so the caller could once again ignore the callee)

How is the logic implemented in MRI for 2.7?

Specializing the caller for a given callee is a well-known technique.
However, it becomes more difficult if different methods are called from the same callsite (polymorphic call), especially if one accepts kwargs and another does not.
In that case, I think we will see a performance cost to this approach, by having to pass arguments differently based on the method to be called.

What about delegation using `ruby2_keywords`?
Which checks does that add (compared to 2.6) in the merged approach with the Hash flag?



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>