Bug #11396
Updated by brunoe (Bruno Escherl) over 9 years ago
This started out as an issue on stackoverflow, where I found strange performance anomalies when comparing Set.include? and Array.include? in different ruby versions: http://stackoverflow.com/questions/31631284/performance-anomaly-in-ruby-set-include-with-symbols-2-2-2-vs-2-1-6
In the end it came down to problems with lookup of Hash keys. While for smaller Hashes the performance issues went away using ruby_2_2 branch, they staid for bigger Hashes. I'll attach a benchmark script (hash_bench_3.rb) I used that creates a Hash with 200000 keys and does a lookup of 10000 of them.
Here my results:
ruby 2.1.6p336 (2015-04-13 revision 50298) [x86_64-darwin14.0]
string 142.818 (± 2.8%) i/s - 714.000
symbol 505.831 (± 3.0%) i/s - 2.550k
ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin14]
string 143.404 (± 3.5%) i/s - 728.000
symbol 76.945 (± 6.5%) i/s - 385.000
ruby 2.2.3p147 (2015-07-04 revision 51143) [x86_64-darwin14] self-compiled (self-compiled)
string 138.349 (± 2.2%) i/s - 702.000
symbol 77.495 (± 3.9%) i/s - 392.000
As you can see 2.2 is much slower than 2.1.6 for symbol keys. I was recommended to disable Garbage Collection for Symbols for testing and did so on the ruby_2_2 branch
ruby 2.2.3p147 (2015-07-04 revision 51143) [x86_64-darwin14] self-compiled, USE_SYMBOL_GC=0 (self-compiled, USE_SYMBOL_GC=0)
string 145.179 (± 3.4%) i/s - 728.000
symbol 602.008 (± 7.6%) i/s - 3.050k
I would have expected that symbol GC may have some performance impact, but this looks like it is too big. I can't say exactly at which point Garbage Collection really hurts, but the bigger the Hash and the bigger the number of include? calls, the slower it gets.