Issue #18733 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Closed Re-checked on master 4d185cce78 (4.1.0dev). The gap this ticket is about is gone. I used jhawthorn's variant of the benchmark from #note-4 (`[0,1].itself.include?(n)`, so the array literal is not elided), fib(34) in 8 workers, with fork and Ractor measured alternately inside the same process, two rounds each: ruby fork wall ractor wall ractor/fork ractor cpu/wall (max 8) master 4d185cce78 2.12 / 2.26 2.03 / 2.09 x0.96 / x0.92 7.89 / 7.85 4.0.2 2.57 / 2.64 5.36 / 6.56 x2.08 / x2.49 3.56 / 3.09 3.4.4 2.76 / 2.91 89.8 / 94.5 x32.6 / x32.4 1.64 / 1.61 3.3.2 2.57 / 2.74 115.6 / 83.1 x45.0 / x30.3 1.80 / 2.08 On master the Ractor version is as fast as fork and uses 7.85-7.89 of the 8 cores; the remaining difference is run-to-run noise. The big step is the per-Ractor GC work (GH-18194, merged 2026-08-07), which is in master but not in 4.0: allocation-heavy Ractors no longer serialise on a global GC. (I did not bisect; this is a version-level attribution. The earlier 3.4 -> 4.0 step, x32 -> x2, is separate GC work.) Measured on an idle 16-core Linux box. Only the fork/Ractor ratio within one run should be read, not the absolute times. ---------------------------------------- Bug #18733: Heavy GC allocations cause performance issue with Ractor https://bugs.ruby-lang.org/issues/18733#change-118837 * Author: jakit (Jakit Liang) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Code: ``` require 'benchmark' def fib(n) return n if [0,1].include?(n) fib(n-1) + fib(n-2) end tp = [] puts Benchmark.measure { 8.times do tp << fork { fib(37) } end tp.each { |t| Process.wait(t) } } puts Benchmark.measure { 8.times.map { Ractor.new { fib(37) } }.each{ |r| r.take } } ``` Result: |A |B | |--|--| | fork | 0.000264 0.003439 87.181198 ( 11.211349) | | Ractor | 80.292916 15.062559 95.355475 ( 39.569527) | And I found that here's the problem showing on the ActiveMonitor.app:  As you can see, the process of ruby is always using all Performance Cores on my Apple M1 Mac. But there's no one of the Efficiency Cores was in used by ruby Ractor. -- https://bugs.ruby-lang.org/