Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
wants to merge 3 commits into from
Closed

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

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a759a25
Add benchmark for Hash#dig vs #[] vs #fetch
dideler Mar 18, 2016
95b8ea4
Also benchmark the more common `Hash#[] &&` style
dideler Mar 18, 2016
437d8f8
:memo: Introduce Hash#dig and link to more info
dideler Mar 20, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
29 changes: 29 additions & 0 deletions README.md
View file
Open in desktop
Expand Up @@ -573,6 +573,35 @@ Comparison:
Hash#fetch, string: 3981166.5 i/s - 1.89x slower
```

##### `Hash#dig` vs `Hash#[]` vs `Hash#fetch` [code](code/hash/dig-vs-[]-fetch.rb)

```
$ ruby -v code/hash/dig-vs-\[\]-vs-fetch.rb
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]
Warming up --------------------------------------
Hash#dig 142.217k i/100ms
Hash#[] 153.313k i/100ms
Hash#[] || 145.380k i/100ms
Hash#[] && 121.401k i/100ms
Hash#fetch 137.236k i/100ms
Hash#fetch fallback 120.010k i/100ms
Calculating -------------------------------------
Hash#dig 6.216M (± 6.2%) i/s - 31.003M
Hash#[] 6.676M (± 6.3%) i/s - 33.269M
Hash#[] || 6.160M (± 6.2%) i/s - 30.675M
Hash#[] && 3.096M (± 5.4%) i/s - 15.539M
Hash#fetch 4.425M (± 5.5%) i/s - 22.095M
Hash#fetch fallback 3.279M (± 5.3%) i/s - 16.441M

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
```

##### `Hash[]` vs `Hash#dup` [code](code/hash/bracket-vs-dup.rb)

Source: http://tenderlovemaking.com/2015/02/11/weird-stuff-with-hashes.html
Expand Down
31 changes: 31 additions & 0 deletions code/hash/dig-vs-[]-vs-fetch.rb
View file
Open in desktop
@@ -0,0 +1,31 @@
require 'benchmark/ips'

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

Benchmark.ips do |x|
x.report 'Hash#dig' do
h.dig(:a, :b, :c, :d, :e)
end

x.report 'Hash#[]' do
h[:a][:b][:c][:d][:e]
end

x.report 'Hash#[] ||' do
((((h[:a] || {})[:b] || {})[:c] || {})[:d] || {})[:e]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

end

x.report 'Hash#[] &&' do
h[:a] && h[:a][:b] && h[:a][:b][:c] && h[:a][:b][:c][:d] && h[:a][:b][:c][:d][:e]
end

x.report 'Hash#fetch' do
h.fetch(:a).fetch(:b).fetch(:c).fetch(:d).fetch(:e)
end

x.report 'Hash#fetch fallback' do
h.fetch(:a, {}).fetch(:b, {}).fetch(:c, {}).fetch(:d, {}).fetch(:e, nil)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

end

x.compare!
end