[ruby-core:26662] Re: HashWithIndifferentAccess to core

On Tue, Nov 10, 2009 at 1:44 AM, Jeremy Kemper <[e-mail]> wrote:


> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 user =A0 =A0 syst=
em =A0 =A0 =A0total =A0 =A0 =A0 =A0real
> rails #[:abc] =A0 =A0 =A0 =A0 =A0 =A00.280000 =A0 0.000000 =A0 0.280000 (=
 =A00.287421)
> rails #["ab"] =A0 =A0 =A0 =A0 =A0 =A00.070000 =A0 0.000000 =A0 0.070000 (=
 =A00.078379)
>
> Benchmark at http://github.com/jeremy/rails/blob/hwia/activesupport/hwia.=
rb

It's good to have real numbers.

I'm a bit surprised by the difference between these two.  I think this
is because of a subtle performance bug in the current implementation.

Instead of overriding Hash#[] HWIA overrides Hash#fetch.

Looking at both Ruby 1.8 and 1.9, Hash#[] is implemented by
rb_hash_aref, Hash#fetch is implemented by rb_hash_fetch in 1.8 and
rb_hash_fetch_m in 1.9.

So when we invoke the [] method of HWIA, what happens.

Since it isn't overriden, we just invoke Hash#[], if the key is a key
in the hash, bob's your uncle,  if it's it's not (which it won't if if
is a Symbol) then rb_hash_aref invokes the default method, which IS
overridden by HWIA:

  def default(key =3D nil)
    if key.is_a?(Symbol) && include?(key =3D key.to_s)
      self[key]
    else
      super
    end
  end

So for symbol keys we end up doing.

   1) a failed search in the hash
   2) a conversion of the symbol to a string
   3) a search in the hash to see if that string is a key and if it is
   4) another search in the hash to get the value

So I suspect that if the ActiveSupport HashWithIndifferentAccess
overrode Hash#[] with code like that in it's implementation of Fetch,
that the performance of access via a symbol key would be nearly as
fast as access via the equivalent symbol.  This would change it from
being an "Error recovery" pattern to a normal pattern.

It might be possible to do this by aliasing the methods, although
there are some differences in the arity Hash#[] has arity 1, while
Hash#fetch is arity -1.

I also think there may be another significant functional difference
between the AS HWIA and the other two implementations you are
benchmarking.

AS HWIA checks the value being assigned in  []=3D, and if it's a Hash,
turns it into a HWIA before storing it, this allows the right thing to
happen with nested hashes, a common case with uri parameters.


--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale