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 1 commit
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.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -573,6 +573,32 @@ 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 144.192k i/100ms
Hash#[] 148.853k i/100ms
Hash#[] fallback 149.761k i/100ms
Hash#fetch 132.257k i/100ms
Hash#fetch fallback 120.420k i/100ms
Calculating -------------------------------------
Hash#dig 6.253M (± 5.9%) i/s - 31.145M
Hash#[] 6.733M (± 5.9%) i/s - 33.641M
Hash#[] fallback 6.209M (± 5.7%) i/s - 31.001M
Hash#fetch 4.500M (± 5.0%) i/s - 22.484M
Hash#fetch fallback 3.330M (± 4.7%) i/s - 16.618M

Comparison:
Hash#[]: 6732624.6 i/s
Hash#dig: 6252809.1 i/s - same-ish: difference falls within error
Hash#[] fallback: 6209365.5 i/s - same-ish: difference falls within error
Hash#fetch: 4499831.0 i/s - 1.50x slower
Hash#fetch fallback: 3330397.7 i/s - 2.02x 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
27 changes: 27 additions & 0 deletions code/hash/dig-vs-[]-vs-fetch.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
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#[] fallback' 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#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