From: eregontp@... Date: 2019-10-27T10:41:06+00:00 Subject: [ruby-core:95569] [Ruby master Misc#16188] What are the performance implications of the new keyword arguments in 2.7 and 3.0? Issue #16188 has been updated by Eregon (Benoit Daloze). I want to expand on my semantics concern, for the performance concern I should get some numbers first. jeremyevans0 (Jeremy Evans) wrote: > Technically, `**hash` automatically converts a positional hash to keywords. So I definitely think we want a way to automatically convert from positional hash to keywords, otherwise all keyword arguments would need to be specified explicitly in every call. Yes of course. What I meant is `ruby2_keywords` is the only thing which allows passing keyword arguments without explicitly using `**` or literal keywords (`foo(a: 1)`) at the call site (those 2 are explicit and fine). For instance, `bar(*args)` from the code above passes keyword arguments even though no Ruby code should be able to do that in 3.0, but `ruby2_keywords` is an exception here. It's not so nice that `somecall(*args)` behaves differently depending on whether `Hash === args[-1] && tagged?(args[-1])` (which is not a property of the lexical code, but a dynamic runtime flag). So looking at some Ruby code in some gem, I cannot know if `somecall(*args)` may pass or never passes keyword arguments. Having an explicit `send_keyword_hash` would fix that and mark the only places that might take `*args` but actually pass keyword arguments too. @mame What do you think of that specific concern? ---------------------------------------- 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-82350 * 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: