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 E8C6D1F463 for ; Sun, 24 Nov 2019 20:54:23 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E36D912099F; Mon, 25 Nov 2019 05:54:08 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 9227D1208FB for ; Mon, 25 Nov 2019 05:54:06 +0900 (JST) Received: by filter0161p3mdw1.sendgrid.net with SMTP id filter0161p3mdw1-31815-5DDAEDF2-6 2019-11-24 20:54:10.456335396 +0000 UTC m=+421097.343609812 Received: from herokuapp.com (unknown [3.87.184.74]) by ismtpd0046p1iad1.sendgrid.net (SG) with ESMTP id AuOMEjaySU6pyhX26fG9-g for ; Sun, 24 Nov 2019 20:54:10.370 +0000 (UTC) Date: Sun, 24 Nov 2019 20:54:10 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71559 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr3Fyg9btFmxMx49URDfMT?= =?us-ascii?Q?C+4eBk314+eNjV46klMqVx57wK2PGbDJ+p9IazH?= =?us-ascii?Q?L=2FZf5N3I3gyi1fV9E74nWB76Y1rz=2FIqrcL2t39j?= =?us-ascii?Q?8CgyDR6Yqks5we8WPFYCl+KM5IJXDjGiuuSTgBm?= =?us-ascii?Q?800SABRamOojsB39emvLQJj6+GGJ71PGUAA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95925 Subject: [ruby-core:95925] [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: > On CRuby master branch, in the worst possible case I could design, the difference was about 1%. Why is `def a(x) end; a(*arr)` the worst case? Would it not be more expensive to call a method accepting keyword arguments, since then further logic might be needed? I benchmarked MRI, comparing MRI 2.6.5 with MRI 2.7.0preview3, and I see overheads far above 1%, more in the 10%. There is a bit of noise, even with turbo boost disabled and the performance CPU governor and using CLOCK_THREAD_CPUTIME_ID. However, 2.7 is consistently slower for that benchmark in my measurements. Comparing the last measurement for each: * baseline: 2.7 is 1.3% faster * req: 2.7 is 10.6% slower * kw: 2.7 is 9.7% slower * kwrest: 2.7 is 8% slower See https://gist.github.com/eregon/15ebe02ff8f42c0ab964e1066a783f9d for all numbers and the benchmark. Those overheads are probably not entirely due to `ruby2_keywords` (I would think a good part is, though). The fact the baseline results are quite close seems to indicate that at least `req(1)` is not slower on Ruby 2.7 (in fact, it's a bit faster). However, all 3 `foo(*args)` seem to show a general 8-10% slowdown in Ruby 2.7, which I'd guess is due to `ruby2_keywords`. ---------------------------------------- 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-82765 * 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/