Add benchmark for Hash#dig vs #[] vs #fetch

[dideler]

Comparison of how Ruby 2.3.0's Hash#dig performs to similar methods.

Unsafe retrieval options are included. I can remove them if you consider them noisy.

[nateberkopec]

ouch, do people ever really do it this way? far more common I think is:

h[:a] && h[:a][:b] && ## etc

[dideler]

I'm not sure which way is more common. Should I use one example over the other or include both?

[deniskorobicyn]

Actually, I think, the way proposed by @nateberkopec is more effective in case when none of the keys are exists, because you don't need to create all of these hashes.

[dideler]

I've added the more common style to the benchmark, see 95b8ea4

[ixti]

fetch(:a, {}) creates new object EVERY time even when it's not needed.
More appropriate would be:

h.fetch(:a) { {} }.fetch(:b) { {} }...

[mblumtritt]

Your notation will create Procs for every #fetch. That maybe faster or not. Seems that's another test… :)

[dideler]

@ixti I'd like to keep it as is because I see the current approach more often.

[ixti]

@mblumtritt in fact it will not. Why would it create Proc?

In any case, @dideler I tend to agree that probably some people use fetch(key, {}).
And that looks pretty fine, but in this case it worth to "cache" that object:

o = {}
h.fetch(:a, o).fetch(:b, o)

That's just my thoughts. I don't insist on anything :D

[ixti]

More interesting would be to compare dig vs alternatives upon "broken" path:

H = { :a => { :b => { :d => true } } }

H.dig(:a, :b, :c, :d) # => nil
H[:a] && H[:a][:b] && H[:a][:b][:c] && H[:a][:b][:c][:d] # => nil

[dideler]

More interesting would be to compare dig vs alternatives upon "broken" path:

I find the safe path most interesting because you can compare more options, but here are all cases.

Safe: h = { a: { b: { c: { d: { e: "foo" } } } } }

Comparison:
             Hash#[]:  6676415.9 i/s
            Hash#dig:  6215966.7 i/s - same-ish: difference falls within error
          Hash#[] ||:  6160177.6 i/s - same-ish: difference falls within error
          Hash#fetch:  4424551.0 i/s - 1.51x slower
 Hash#fetch fallback:  3278599.3 i/s - 2.04x slower
          Hash#[] &&:  3096090.4 i/s - 2.16x slower

Broken at last key: h = { a: { b: { c: { d: { x: "foo" } } } } }
The Hash#fetch benchmark is excluded because it doesn't gracefully fail.

Comparison:
             Hash#[]:  6391117.6 i/s
          Hash#[] ||:  5775857.7 i/s - same-ish: difference falls within error
            Hash#dig:  5599916.6 i/s - same-ish: difference falls within error
 Hash#fetch fallback:  3278820.7 i/s - 1.95x slower
          Hash#[] &&:  2920215.9 i/s - 2.19x slower

Broken at intermediate key: h = { a: { b: { c: { x: { e: "foo" } } } } }
The Hash#fetch and Hash#[] benchmarks are excluded because they do not gracefully fail.

Comparison:
            Hash#dig:  5525802.5 i/s
          Hash#[] ||:  4866123.4 i/s - same-ish: difference falls within error
          Hash#[] &&:  3727126.8 i/s - 1.48x slower
 Hash#fetch fallback:  2921706.4 i/s - 1.89x slower

Hash#dig does well in all cases. It reads better than the other options and is consistently performant.

[ixti]

@dideler I'm absolutely agree that dig is a winner :D and I guess the only my proposal is to add link to #102 (comment) in readme :D

[dideler]

👍, how's 437d8f8?

[ixti]

LGTM! 👍

[JuanitoFatas]

Thanks everyone 👏 ! Merged as d6e1ac0.

@dideler Dennis would you like to be a collaborator to this repository 😊 ?

[dideler]

Thanks @JuanitoFatas - I would love to be a collaborator!

[JuanitoFatas]

Thanks @JuanitoFatas - I would love to be a collaborator!

Yay! ❤️