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-Status: No, score=-2.6 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,UNPARSEABLE_RELAY 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 B429C1F66F for ; Wed, 4 Nov 2020 00:17:39 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D9E571209A4; Wed, 4 Nov 2020 09:16:53 +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 39E08120939 for ; Wed, 4 Nov 2020 09:16:51 +0900 (JST) Received: by filterdrecv-p3las1-59c958db66-tbk76 with SMTP id filterdrecv-p3las1-59c958db66-tbk76-18-5FA1F313-1E 2020-11-04 00:17:23.821033061 +0000 UTC m=+689823.760609622 Received: from herokuapp.com (unknown) by geopod-ismtpd-3-3 (SG) with ESMTP id pa6XBPmTTIaUf5ZQHm12Yg for ; Wed, 04 Nov 2020 00:17:23.608 +0000 (UTC) Date: Wed, 04 Nov 2020 00:17:23 +0000 (UTC) From: muraken@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 76579 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17291 X-Redmine-Issue-Author: mrkn X-Redmine-Issue-Assignee: matz X-Redmine-Sender: mrkn 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?zpFjjZpImXPpY=2FcRIKDq1ipXkOYTu+Zo9t1k7iA7niAdq20QDeN=2F7KCnFomrq8?= =?us-ascii?Q?7nfeJPcaqScBmkmTOC5UPLiBEBykbQc0bc2JnjA?= =?us-ascii?Q?azVEczkQaEKkfxo9fctLVLl0Dibi0zTtT4cibdM?= =?us-ascii?Q?ztzsDOwwouEiXL7xD3d4kNjY4LjVuM5ry+4+H1s?= =?us-ascii?Q?HgIWXh4+LvE=2FiCEsvx4bYhun4e6qU83mlMGt8pN?= =?us-ascii?Q?rpxbStFnFEXmO0eRs=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 100707 Subject: [ruby-core:100707] [Ruby master Feature#17291] Optimize __send__ call 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 #17291 has been updated by mrkn (Kenta Murata). I found that rspec-core redefines `__send__`. https://github.com/rspec/rspec-mocks/blob/461d7f6f7f688f69154e410dcd9c7690120e7dbf/lib/rspec/mocks/verifying_double.rb#L45-L53 ---------------------------------------- Feature #17291: Optimize __send__ call https://bugs.ruby-lang.org/issues/17291#change-88351 * Author: mrkn (Kenta Murata) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- I made a patch to optimize a `__send__` call. This optimization replaces a `__send__` method call with a call of the method whose name is the first argument of `__send__` method. The patch is available in [this pull-request](https://github.com/ruby/ruby/pull/3720). By this change, the redefined `__send__` method is no longer called when it is called by a symbol method name. I guess it is no problem because the following warning message is displayed for a long time. $ ruby -e 'def __send__; end' -e:1: warning: redefining `__send__' may cause serious problems This proposal introduces two new instructions: `sendsym` and `opt_sendsym_without_block`. These instructions handle the cases that the first argument of `__send__` method is not a symbol literal. I think I can combine these two instructions into one if prefered. This proposal includes the change proposed in #17288. I'll mark it as a duplicate of this proposal. I don't handle `send` method in this proposal. The reason is that we need to examine the redefinition of `send` method in the instruction execution time. I want to discuss only `__send__` method in this ticket. The benchmark result is below: ``` # Iteration per second (i/s) | |compare-ruby|built-ruby| |:----------------|-----------:|---------:| |vm_send_sym | 18.001M| 112.208M| | | -| 6.23x| |vm_send_var | 17.779M| 30.922M| | | -| 1.74x| |vm_send_var_alt | 3.817M| 6.817M| | | -| 1.79x| ``` -- https://bugs.ruby-lang.org/