From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.7 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 348E71F4C0 for ; Wed, 23 Oct 2019 16:05:40 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 6B297120AA7; Thu, 24 Oct 2019 01:05:30 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 2AD6F120AA6 for ; Thu, 24 Oct 2019 01:05:27 +0900 (JST) Received: by filter0186p3mdw1.sendgrid.net with SMTP id filter0186p3mdw1-13118-5DB07A4A-C0 2019-10-23 16:05:30.711458172 +0000 UTC m=+149099.476794652 Received: from herokuapp.com (unknown [52.91.158.104]) by ismtpd0056p1iad1.sendgrid.net (SG) with ESMTP id c2gng73OSZeEXCTtcvRA1w for ; Wed, 23 Oct 2019 16:05:30.655 +0000 (UTC) Date: Wed, 23 Oct 2019 16:05:30 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71096 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16188 X-Redmine-Issue-Author: Eregon X-Redmine-Issue-Assignee: jeremyevans0 X-Redmine-Sender: Eregon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr1TN4m7tM82Da05lwhwyF?= =?us-ascii?Q?FV0g7Bvz5cygjlzyT2gRI=2FqEuo6oMbJj1YY3iR3?= =?us-ascii?Q?p+vp5aCbap64Ykb=2FY38DBjH62isaS54YQpTdS8C?= =?us-ascii?Q?2OLM5YOQK8+fwmbtqIMP+DdCc2Derdydd5kdMWx?= =?us-ascii?Q?HcFUqkAGluepamhdNwM5QGYCWh1QCrdGZDw=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95504 Subject: [ruby-core:95504] [Ruby master Misc#16188] What are the performance implications of the new keyword arguments in 2.7 and 3.0? X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16188 has been updated by Eregon (Benoit Daloze). jeremyevans0 (Jeremy Evans) wrote: > You shouldn't even take your word, as you haven't implemented it yet. I'll post a benchmark, and I ask you to do the same. Fair enough, I'll try to benchmark this soon in TruffleRuby then. If I can have a call with you it would be helpful to discuss the conceptual implementation for that logic and what examples are good to compare (and ideas related to delegation). > > For me, it ruins a good part of the performance advantages of separating positional and keyword arguments, because once again there is automatic conversion and "keywords split out from the last Array argument". > > Separating positional and keyword arguments was not done for performance reasons, it was done to avoid the issues that not separating them caused. I know, but I think separating arguments can be an opportunity for better performance performance and cheaper method/block calls, and this partially removes that opportunity. Also on the semantics level, I think it would be cleaner if there are no ways to automatically convert a positional Hash to kwargs or vice-versa. Don't you agree? By having `ruby2_keywords` in Ruby 3, we're probably going to see some abuse of it, and some confusion about it. If the goal is to separate positional and keyword arguments, why are we leaving a backdoor? > The initial proposal for `ruby2_keywords` used a VM frame flag and not a hash object flag, and was thus localized. Unfortunately, it didn't handle cases that people wanted it to handle. I think Ruby's goal of programmer happiness should outweigh minor theoretical performance issues. Yes the frame flag approach was better performance-wise in that it would only affect a known small set of call sites. > > I think it's a straightforward way to mark exactly which call sites need the legacy conversion behavior. > > There are likely rather few of those, and it seems worth to avoid degrading the performance of all other call sites with a `*rest` argument and no kwargs. > > `Kernel#send_keyword_hash` requires changing the method definition or adding a separate method definition, when one of the main benefits of `ruby2_keywords` is that you do not need to modify an existing method definition. Yes, it requires changing the method definition, but in a fairly obvious way. I would argue everyone changing a delegation method knows very well which is the delegating call site, and marking it with `send_keyword_hash` is completely trivial. I'd think it's even useful to mark and correspondingly to not mark some call sites which should not pass kwargs. The current logic where Array#dup dup's the last argument if it's a tagged Hash (6081ddd6e6f2297862b3c7e898d28a76b8f9240b) seems a particularly not nice workaround for the fact a tagged Hash might be used as kwargs multiple times. `#send_keyword_hash` would solve this in a more clean, explicit and clear way. I don't think there is much of a difference to add `ruby2_keywords`, a "visibility modifier" before `def` vs modifying a call site. Both need modifications of the file. ---------------------------------------- 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-82280 * 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/