From: shyouhei@ruby-lang.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:100664] [Ruby master Feature#17291] Optimize __send__ call
Date: Fri, 30 Oct 2020 00:21:53 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-88304.20201030002153.482@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17291.20201029030545.482@ruby-lang.org
Issue #17291 has been updated by shyouhei (Shyouhei Urabe).
I'm neutral (at least no against it). `__send__` in general has other usages than to reroute method visibilities. Optimising it could benefit good wills.
----------------------------------------
Feature #17291: Optimize __send__ call
https://bugs.ruby-lang.org/issues/17291#change-88304
* 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/
next prev parent reply other threads:[~2020-10-30 0:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 3:05 [ruby-core:100631] [Ruby master Feature#17291] Optimize __send__ call muraken
2020-10-30 0:21 ` shyouhei [this message]
2020-11-04 0:17 ` [ruby-core:100707] " muraken
2020-11-04 3:29 ` [ruby-core:100709] " shyouhei
2020-11-04 10:53 ` [ruby-core:100712] " eregontp
2020-11-06 16:45 ` [ruby-core:100728] " muraken
2020-11-06 16:46 ` [ruby-core:100729] " muraken
2021-01-12 5:47 ` [ruby-core:102019] " muraken
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-88304.20201030002153.482@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).