From: "Matthias Wächter" <redmine@...>
Date: 2009-01-27T01:31:02+09:00
Subject: [ruby-core:21568] [Feature #1055] Performance Issues with nil, true, false as Hash Keys

Feature #1055: Performance Issues with nil, true, false as Hash Keys
http://redmine.ruby-lang.org/issues/show/1055

Author: Matthias W��chter
Status: Open, Priority: Normal

as reported in [ruby-talk:272146] and later in [ruby-core:12414], ruby 1.8.6, 1.8.7 as well as trunk suffer from a performance degradation if some well-known immediates are used as hash keys:

from [ruby-talk:272146]:
> test_int.rb          37.029
> test_var_int.rb      37.659
> test_symbol.rb       37.773
> test_var_symbol.rb   37.785
> test_var_frozen.rb   37.852
> test_var_string.rb   40.515
> test_var_false.rb    45.468
> test_false.rb        45.687
> test_var_nil.rb      45.894
> test_nil.rb          46.068
> test_string.rb       53.032

As pointed out in the mails, the function rb_any_hash performs some useful optimizations based on the object type for T_FIXNUM, T_SYMBOL and T_STRING, but the optimization does not cover T_NIL, T_FALSE and T_TRUE. Attached is a patch against trunk that fixes this significant performance degradation.

Depending on compiler optimization, performance could be raised by replacing the switch() with a check for SPECIAL_CONST_P() for the first case, then a check for T_STRING against the result of BUILTIN_TYPE().

The patch should be applicable to the 1.8, 1.8.7 and 1.8.6 branches as well.


----------------------------------------
http://redmine.ruby-lang.org