https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112020-05-07T21:02:02ZRuby Issue Tracking SystemRuby master - Bug #16840: Decrease in Hash#[]= performance with object keyshttps://redmine.ruby-lang.org/issues/16840?journal_id=854472020-05-07T21:02:02Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/16837">Feature #16837</a>: Can we make Ruby 3.0 as fast as Ruby 2.7 with the new assertions?</i> added</li></ul> Ruby master - Bug #16840: Decrease in Hash#[]= performance with object keyshttps://redmine.ruby-lang.org/issues/16840?journal_id=857012020-05-18T22:37:10Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul><li><strong>Subject</strong> changed from <i>Why is Ruby getting slower in every version?</i> to <i>Decrease in Hash#[]= performance with object keys</i></li></ul><p>Running your example code, I see a speedup between 2.5 and 2.6, but a slowdown in 2.7 and in master.</p>
<pre><code>ruby 2.5.8p224 (2020-03-31 revision 67882) [x86_64-openbsd]
10.040000 0.010000 10.050000 ( 10.089013)
9.930000 0.010000 9.940000 ( 10.060374)
9.850000 0.010000 9.860000 ( 10.048056)
ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-openbsd]
9.450000 0.020000 9.470000 ( 9.588573)
9.470000 0.010000 9.480000 ( 9.582035)
9.500000 0.010000 9.510000 ( 9.607103)
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-openbsd]
10.610000 0.010000 10.620000 ( 10.825456)
10.660000 0.030000 10.690000 ( 10.845059)
10.670000 0.000000 10.670000 ( 10.980962)
# Not sure if compile flags are exactly the same as the above
ruby 2.8.0dev (2020-05-19) [x86_64-openbsd6.7]
11.670000 0.010000 11.680000 ( 11.735787)
11.380000 0.040000 11.420000 ( 11.631791)
11.410000 0.010000 11.420000 ( 11.677220)
</code></pre>
<p>These numbers show a ~20% performance decrease in a specific microbenchmark (<code>Hash#[]=</code> using objects as keys) between 2.6 and master. The difference between 2.6 and 2.7 could be related to #object_id changes. A similar benchmark with string keys shows no performance decrease between 2.6 and 2.7, for example. The difference between 2.7 and master could be related to the new assertions, which will hopefully be compiled out before release.</p>
<p>The percentage difference between versions in your benchmark output is much higher. It would be a good idea to get output from more people. The percentage difference may vary widely depending on hardware, compiler, and compilation flags used.</p> Ruby master - Bug #16840: Decrease in Hash#[]= performance with object keyshttps://redmine.ruby-lang.org/issues/16840?journal_id=925312021-06-16T14:52:29Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Apparently this case was optimized in Ruby 3.0. Using the benchmark code provided:</p>
<pre><code>$ for x in 25 26 27 30; do ruby$x -v; for y in 1 2 3; do ruby$x t/t51.rb; done; done
ruby 2.5.9p229 (2021-04-05 revision 67939) [x86_64-openbsd]
10.040000 0.010000 10.050000 ( 10.045536)
9.970000 0.010000 9.980000 ( 9.995454)
10.170000 0.000000 10.170000 ( 10.180147)
ruby 2.6.7p197 (2021-04-05 revision 67941) [x86_64-openbsd]
9.340000 0.000000 9.340000 ( 9.326443)
9.420000 0.010000 9.430000 ( 9.425656)
9.300000 0.020000 9.320000 ( 9.327280)
ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [x86_64-openbsd]
10.790000 0.020000 10.810000 ( 10.809778)
10.840000 0.020000 10.860000 ( 10.866930)
10.820000 0.010000 10.830000 ( 10.852136)
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-openbsd]
4.780000 0.020000 4.800000 ( 4.798934)
4.760000 0.020000 4.780000 ( 4.770590)
4.720000 0.050000 4.770000 ( 4.774958)
</code></pre>
<p>Possibly due to <a class="changeset" title="any_hash: do not goto into a branch I'm not necessarily against every goto in general, but jumpi..." href="https://redmine.ruby-lang.org/projects/ruby-master/repository/git/revisions/5f6053824551aec947a1c53d08975595aca1e513">5f6053824551aec947a1c53d08975595aca1e513</a>, which changed from an else if chain to a switch, but I didn't confirm that. Anyway, since it's now much faster than before, I think this can be closed.</p>