January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120794] [Ruby master Bug#21089] Missing methods on enumerators created from Enumerator::product and Enumerator::Chain
by zetter (Chris Zetter) 27 Jan '25

27 Jan '25

Issue #21089 has been reported by zetter (Chris Zetter). ---------------------------------------- Bug #21089: Missing methods on enumerators created from Enumerator::product and Enumerator::Chain https://bugs.ruby-lang.org/issues/21089 * Author: zetter (Chris Zetter) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-26T08:52:22Z master d4a1a2780c) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I was using `Enumerator.product` and noticed the enumerators it returned were missing the `next` method. When looking at the source code, I saw all the stateful enumerator methods were missing (`next`, `peek_values`, `peek`, `next_values`, `feed`) as they were removed from the `Enumerator::Product` subclass with `rb_undef_method`. This also applies to instances of `Enumerator::Chain`, it looks like the methods never worked and were removed in https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/68… Because the English documentation says `Enumerator.product` 'Generates a new enumerator object' and the documentation says it inherits from `Enumerator` I expected it to have the `next` method available. I can use `.to_enum` to make the next method available, but I'm not sure why I need to. I'm unsure if this could be solved by making these available or the documentation could be improved. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115117] [Ruby master Bug#19967] Already installed libruby.dylib is used for test on macOS
by nobu (Nobuyoshi Nakada) 24 Jan '25

24 Jan '25

Issue #19967 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19967: Already installed libruby.dylib is used for test on macOS https://bugs.ruby-lang.org/issues/19967 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- On macOS, in the case of `--enable-shared` and `--disable-load-relative`, already install libruby.dylib is used during tests if exists. This is because since [Bug #14992], `DYLD_FALLBACK_LIBRARY_PATH` is used instead of `DYLD_LIBRARY_PATH`. The latter environment variable is used preferentially, whereas the former is used as a fallback, as the name implies. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120748] [Ruby master Bug#21083] current SystemCallError.new(-1) behavior on windows is not in accordance with the intent of the source code.
by YO4 (Yoshinao Muramatsu) 23 Jan '25

23 Jan '25

Issue #21083 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21083: current SystemCallError.new(-1) behavior on windows is not in accordance with the intent of the source code. https://bugs.ruby-lang.org/issues/21083 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- spec/ruby/core/exception/system_call_error_spec.rb says ``` platform_is :windows do SystemCallError.new(-1).message.should == "The operation completed successfully." end ``` but source code says ```if (e < 0) e = GetLastError();``` at win32/win32.c(2838,9) [1] So it appears that the intent is to retrieve previous errors. This is not what the spec intended. It seems that at some point the behavior was broken because the WIN32API TlsGetValue() sets LastError even if it succeeds. SystemCallError.new(-1).errno returns -1 instead of GetLastError() returns, so the current behavior is not very useful. In my opinion, it is preferable to return "Unknown Error #{e}" as on other platforms. This change needs to revert ruby/spec@328ac37 [2] [1] https://github.com/ruby/ruby/blob/2b1db0faecf03d3fa1b7a1b102cc4c51aa962d5f/… [2] https://github.com/ruby/spec/commit/328ac37 BACKGROUND I state the situation because I may be wrong in my guess. I was trying to make changes to allow Language TLS to be used on Windows, but found this spec fails. ``` 1) SystemCallError.new sets an 'unknown error' message when an unknown error number FAILED Expected "The system cannot find message text for message number 0x%1 in the message file for %2." == "The operation completed successfully." to be truthy but was false D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:104:in 'block (3 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:103:in 'block (2 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:22:in '<top (required)>' 2) SystemCallError.new adds a custom error message to an 'unknown error' message when an unknown error number and a custom message specified FAILED Expected "The system cannot find the path specified. - custom message" == "The operation completed successfully. - custom message" to be truthy but was false D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:114:in 'block (3 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:113:in 'block (2 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:22:in '<top (required)>' ``` message 1) because the previous execution of SystemCallError.new(2**24) failed to retrieve the message. MinGW(UCRT64) and VS2022 got same but VS2015 and VS2019 got different message "The resource loader cache doesn't have loaded MUI entry." message 2) I am not sure where this message was obtained from. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120765] [Ruby master Feature#21086] Declare rb_profile_frames() family as async-signal-safe
by osyoyu (Daisuke Aritomo) 23 Jan '25

23 Jan '25

Issue #21086 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21086: Declare rb_profile_frames() family as async-signal-safe https://bugs.ruby-lang.org/issues/21086 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- Since @ivoanjo 's change in https://github.com/ruby/ruby/pull/11036 , I believe `rb_profile_frames()` and `rb_profile_thread_frames()` could be marked as async-signal-safe. I remember @ko1 had a few reasons not to do so. I'd like to ask what @ko1 thinks now. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:116640] [Ruby master Feature#20249] Print only backtraces in rb_bug(), by default
by osyoyu (Daisuke Aritomo) 23 Jan '25

23 Jan '25

Issue #20249 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #20249: Print only backtraces in rb_bug(), by default https://bugs.ruby-lang.org/issues/20249 * Author: osyoyu (Daisuke Aritomo) * Status: Open * Priority: Normal ---------------------------------------- ## Background When a segfault or some unexpected situation occurs, `rb_bug()` is called and prints some few hundred to thousands of lines. The most helpful parts are (arguably) "Ruby level backtrace information" and "C-level backtrace information", but those parts are buried in the very lengthy report. In particular, the "Other runtime information" which contains the list of loaded features (scripts?) and the process memory map could be extremely long despite it does not come very useful, at least when developing C extensions. Even a minimal report from a simple script would consist of 250 lines and require 7 PgUps on my MacBook Air (13 inch) to reach the backtrace part, which contains all the information I need. ## Proposal My proposal is to default to a "minimal report" mode with a limited set of sections, perhaps only "Ruby level backtrace information" and "C level backtrace information" only When a full report is desired (i.e. for bug reports), the user could re-run the script with an special environment variable, such as `RUBY_FULL_CRASH_REPORT=1`. Rust implmements a similar pattern. It doesn't print the full backtrace on panics by default; instead, it guides the user to re-run the program with `RUST_BACKTRACE=1`. It might be hard to reproduce some crashes and segfaults, especially in long-running daemons. It might be nice to default to the "full" mode when stdout is not a tty, since daemons tend to run in non-tty environments. ## Appendix A typical crash report would look like this: ``` ../../example.rb: [BUG] ruby 3.4.0dev (2024-01-20T15:27:19Z master 366b14c0cd) [arm64-darwin23] -- Crash Report log information -------------------------------------------- (5 lines) -- Control frame information ----------------------------------------------- (~50 lines) -- Ruby level backtrace information ---------------------------------------- (depends on program; typically ~50 lines in Rails) -- C level backtrace information ------------------------------------------- (50+-ish lines, depends on program) -- Machine register context ------------------------------------------------ (~10 lines) -- Threading information --------------------------------------------------- (2 lines) -- Other runtime information ----------------------------------------------- * Loaded script (1 line) * Loaded features (depends on program; 800+ lines in Rails) * Process memory map (depends on environment; around 200 lines?) -- https://bugs.ruby-lang.org/

5 10

[ruby-core:120715] [Ruby master Bug#21045] [patch & workaround] "make test-all" failed with FreeBSD 13.4
by hs (Hideki Sakamoto) 20 Jan '25

20 Jan '25

Issue #21045 has been reported by hs (Hideki Sakamoto). ---------------------------------------- Bug #21045: [patch & workaround] "make test-all" failed with FreeBSD 13.4 https://bugs.ruby-lang.org/issues/21045 * Author: hs (Hideki Sakamoto) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- "make test-all" fails when building Ruby 3.4.1 on FreeBSD 13.4. Build and test steps: <pre> % freebsd-version 13.4-RELEASE-p2 % tar xf ruby-3.4.1.tar.xz % cd ruby-3.4.1/ % ./configure % make % make test-all (snip) 1) Error: TestNetHTTPForceEncoding#test_response_body_encoding_encoding_without_content_type: Errno::ECONNREFUSED: Failed to open TCP connection to localhost:34716 (Connection refused - connect(2) for "localhost" port 34716) /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'TCPSocket#initialize' /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'IO.open' /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'block in Net::HTTP#connect' /tmp/ruby-3.4.1/lib/timeout.rb:185:in 'block in Timeout.timeout' /tmp/ruby-3.4.1/lib/timeout.rb:192:in 'Timeout.timeout' /tmp/ruby-3.4.1/lib/net/http.rb:1657:in 'Net::HTTP#connect' /tmp/ruby-3.4.1/lib/net/http.rb:1636:in 'Net::HTTP#do_start' /tmp/ruby-3.4.1/lib/net/http.rb:1625:in 'Net::HTTP#start' /tmp/ruby-3.4.1/lib/net/http.rb:2369:in 'Net::HTTP#request' /tmp/ruby-3.4.1/lib/net/http.rb:1984:in 'Net::HTTP#get' /tmp/ruby-3.4.1/test/net/http/test_http.rb:1344:in 'TestNetHTTPForceEncoding#fe_request' /tmp/ruby-3.4.1/test/net/http/test_http.rb:1372:in 'TestNetHTTPForceEncoding#test_response_body_encoding_encoding_without_content_type' (snip) Finished tests in 672.429322s, 47.6734 tests/s, 9743.0849 assertions/s. 32057 tests, 6551536 assertions, 0 failures, 7 errors, 192 skips ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-freebsd13.4] *** Error code 7 </pre> ### 1. Seven tests in test/net/http/test_http.rb error with "(Connection refused - connect(2) for "localhost" port #####)" These errors appear to be caused by the client in function "fe_request"( **test/net/http/test_http.rb** ) trying to connect to IPv4 ('127.0.0.1') address: <pre> 1324 CONFIG = { * 1325 'host' => 'localhost', 1326 'proxy_host' => nil, 1327 'proxy_port' => nil, 1328 } 1329 1330 include TestNetHTTPUtils 1331 1332 def fe_request(force_enc, content_type=nil) 1333 @server.mount_proc('/fe') do |req, res| 1334 res['Content-Type'] = content_type if content_type 1335 res.body = "hello\u1234" 1336 end 1337 * 1338 http = Net::HTTP.new(config('host'), config('port')) 1339 http.local_host = Addrinfo.tcp(config('host'), config('port')).ip_address 1340 assert_not_nil(http.local_host) 1341 assert_nil(http.local_port) 1342 1343 http.response_body_encoding = force_enc 1344 http.get('/fe') 1345 end </pre> while the @server on line 12 of **test/net/http/utils.rb** listens on a socket with an IPv6 address (':: 1') when tested with ' **localhost** '. <pre> 9 class HTTPServer 10 def initialize(config, &block) 11 @config = config * 12 @server = TCPServer.new(@config['host'], 0) 13 @port = @server.addr[1] 14 @procs = {} </pre> I wasn't sure if this was a bug to fix. As a workaround, remove the following line from /etc/hosts file to eliminate this error: <pre> ::1 localhost ... </pre> ### 2. make test-all stops with "*** Error code 7" after all tests are finished. This is probably a bug in FreeBSD's make command, but it seems to be caused by two spaces at the end of the last command executed when running make test-all: <pre> exec ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r./tool/lib/_tmpdir "./test/runner.rb" --ruby="./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/.excludes --name=!/memory_leak/ ←(*here!!) </pre> To fix this error, modify common.mk line 317 or 965 using attachments(one or the other is sufficient) : <pre> % patch < patch-common.mk-TEST_EXCLUDE.txt (or) % patch < patch-common.mk-yes-test-all.txt </pre> Then re-create the Makefile so that "make test-all" completes successfully. <pre> % ./configure % make test-all BASERUBY = /usr/local/bin/ruby --disable=gems CC = clang LD = ld LDSHARED = clang -shared CFLAGS = -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wmisleading-indentation -Wundef XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/x86_64-freebsd13.4 -I./include -I. -I./prism -I./enc/unicode/15.0.0 -Dmodular_gc_dir= CPPFLAGS = DLDFLAGS = -Wl,--compress-debug-sections=zlib -Wl,-soname,showflags -fstack-protector-strong -pie SOLIBS = -lexecinfo -lprocstat -lz -lrt -lrt -ldl -lcrypt -lm -lthr LANG = ja_JP.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = no YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/mnt/home/sakamoto/ruby-3.4.1/yjit/target/release/' ./yjit/src/lib.rs FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67) Target: x86_64-unknown-freebsd13.4 Thread model: posix InstalledDir: /usr/bin generating enc.mk generating encdb.h encdb.h unchanged making enc making srcs under enc generating transdb.h transdb.h unchanged making trans making encs generating makefiles ext/configure-ext.mk ext/configure-ext.mk unchanged installing default coverage libraries installing default date_core libraries installing digest libraries installing default digest libraries installing default sha2 libraries installing default fiddle libraries installing default console libraries installing default libraries installing default monitor libraries installing default objspace libraries installing default openssl libraries installing default pathname libraries installing default psych libraries installing default pty libraries installing default ripper libraries installing default libraries installing default socket libraries installing default strscan libraries `ruby' is up to date. Run options: --seed=37281 "--ruby=./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/.excludes --name=!/memory_leak/ -- # Running tests: Finished tests in 669.890724s, 47.8541 tests/s, 9779.2801 assertions/s. 32057 tests, 6551049 assertions, 0 failures, 0 errors, 191 skips ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-freebsd13.4] % </pre> Now "make check" will pass all tests and return "check succeeded" and exit normally (attachment:"ruby34-make-check.txt"). ---Files-------------------------------- patch-common.mk-TEST_EXCLUDE.txt (433 Bytes) patch-common.mk-yes-test-all.txt (373 Bytes) ruby34-make-check.txt (14.7 KB) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:120745] [Ruby master Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by jacobcarlborg (Jacob Carlborg) 20 Jan '25

20 Jan '25

Issue #14582 has been updated by jacobcarlborg (Jacob Carlborg). I'm really interested in using DTrace on Ruby as well. One of the major advantages of DTrace is that it's always available and doesn't require any code changes or restarts of the system that is being instrumented. But with the current way that USDT probes are implemented in Ruby it defeats many of the advantages of DTrace. ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-111578 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120303] [Ruby master Bug#20965] `it` vs `binding.local_variables`
by zverok (Victor Shepelev) 20 Jan '25

20 Jan '25

Issue #20965 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20965: `it` vs `binding.local_variables` https://bugs.ruby-lang.org/issues/20965 * Author: zverok (Victor Shepelev) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- `it` is not available in the list of `binding.local_varaibles`, **unlike** numbered parameters: ```ruby p(proc { binding.local_variables }.call) # [] p(proc { |x| binding.local_variables }.call) # [:x] p(proc { _1; binding.local_variables }.call) # [:_1] p(proc { vars = binding.local_variables; _1; vars }.call) # [:_1, :vars] p(proc { it; binding.local_variables }.call) # [] ``` I wonder if it is deliberate or accidental. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:120736] [Ruby master Feature#21047] Change `*nil` to not call `nil.to_a`, for consistency with `**nil`
by jeremyevans0 (Jeremy Evans) 19 Jan '25

19 Jan '25

Issue #21047 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21047: Change `*nil` to not call `nil.to_a`, for consistency with `**nil` https://bugs.ruby-lang.org/issues/21047 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- In Ruby 3.3, we started accepting `**nil` for keyword splats. This does not call `nil.to_hash`, unlike other uses of `**` for splatting. This made `**nil` handling inconsistent with `*nil` handling, as `*nil` historically has called `nil.to_a`. I propose we make them consistent, by having `*nil` not call `nil.to_a`. Advantage: In addition to more consistent behavior with `**nil`, making `*nil` not call `nil.to_a` opens up new a optimization opportunity, since it allows `*nil` to be optimized to not allocate an array, similar to how `**nil` is already optimized to not allocate a hash. Disadvantage: Minor backwards compatibility breakage, though it is very unlikely any code other than test code will break, because overriding `nil.to_a` to return anything other than the empty array would likely break any large Ruby application. I've submitted a pull request to implement this: https://github.com/ruby/ruby/pull/12597 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111121] [Ruby master Bug#19165] Method (with no param) delegation with *, **, and ... is slow
by matsuda (Akira Matsuda) 16 Jan '25

16 Jan '25

Issue #19165 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19165: Method (with no param) delegation with *, **, and ... is slow https://bugs.ruby-lang.org/issues/19165 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-01T08:05:41Z master 4e68b59431) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I found that method delegation via Forwardable is much slower than normal method call when delegating a method that does not take parameters. Here's a benchmark that explains what I mean. ``` require 'forwardable' require 'pp' require 'benchmark/ips' class Obj extend Forwardable attr_accessor :other def initialize @other = Other.new end def foo_without_splat @other.foo end def foo_with_splat(*) @other.foo(*) end def foo_with_splat_with_name(*args) @other.foo(*args) end def foo_with_splat_and_double_splat(*, **) @other.foo(*, **) end def foo_with_triple_dots(...) @other.foo(...) end delegate :foo => :@other end class Other def foo() end end o = Obj.new Benchmark.ips do |x| x.report 'simple call' do o.other.foo end x.report 'delegate without splat' do o.foo_without_splat end x.report 'delegate with splat' do o.foo_with_splat end x.report 'delegate with splat with name' do o.foo_with_splat_with_name end x.report 'delegate with splat and double splat' do o.foo_with_splat_and_double_splat end x.report 'delegate with triple dots' do o.foo_with_triple_dots end x.report 'delegate via forwardable' do o.foo end end (result) simple call 38.918M (± 0.9%) i/s - 194.884M delegate without splat 31.933M (± 1.6%) i/s - 159.611M delegate with splat 10.269M (± 1.6%) i/s - 51.631M delegate with splat with name 9.888M (± 1.0%) i/s - 49.588M delegate with splat and double splat 4.117M (± 0.9%) i/s - 20.696M delegate with triple dots 4.169M (± 0.9%) i/s - 20.857M delegate via forwardable 9.204M (± 2.1%) i/s - 46.295M ``` It shows that Method delegation with a splat is 3-4 times slower (regardless of whether the parameter is named or not), and delegation with a triple-dot literal is 9-10 times slower than a method delegation without an argument. This may be because calling a method taking a splat always assigns an Array object even when no actual argument was given, and calling a method taking triple-dots assigns five Array objects and two Hash objects (this is equivalent to `*, **`). Are there any chance reducing these object assignments and making them faster? My concern is that the Rails framework heavily uses this kind of method delegations, and presumably it causes unignorable performance overhead. -- https://bugs.ruby-lang.org/

6 8