-
Notifications
You must be signed in to change notification settings - Fork 377
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.
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
Add benchmark for Array#new vs. Fixnum#times + map #91
Add benchmark for Array#new vs. Fixnum#times + map #91
Conversation
When you need to map the result of a block invoked a fixed amount of times, you have an option between: ``` Array.new(n) { ... } ``` and: ``` n.times.map { ... } ``` The latter one is about 60% slower.
@@ -0,0 +1,17 @@ | |||
require "benchmark/ips" | |||
|
|||
ELEMENTS = 9 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this change with the number of elements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nateberkopec: It tapers off a bit, and stabilizes around 40% slower at 1_000
elements and up. Note: logarithmic scale!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for the graph! I'm just getting started with this repo, so someone else should comment, but whenever there's an Array or Enumerable benchmark I'm always curious with how it scales with # of elements. You may want to add a comment explaining that this behaves pretty much the same way at 1 million elements as it does at 10.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problems @nateberkopec. :-) Is a comment in the PR sufficient, or do you want me to add it to the README
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shrug let's see what someone else thinks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote for link to this PR in README.md
.
This'll make info available for everyone, not only for people who reviewing PR's. Also, link will share that cool graph you have here:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nateberkopec, @deniskorobicyn, @JuanitoFatas: Thanks for the kind words. 😃 I added the graph to the PR description, and linked to the PR from the README
.
As suggested by @deniskorobicyn, adding a link from the `README.md` to the PR, which has more information on performance characteristics.
c778665
to
bdfed07
Compare
There's a faster way: require 'benchmark/ips'
LIMIT = 9
def fastest
[].fill(0, LIMIT, &:itself)
end
def fast
Array.new(LIMIT, &:itself)
end
def slow
(0...LIMIT).map(&:itself)
end
def slowest
LIMIT.times.map(&:itself)
end
Benchmark.ips do |bm|
bm.report('Array#fill') { fastest }
bm.report('Array#new') { fast }
bm.report('Range#map') { slow }
bm.report('Fixnum#times') { slowest }
bm.compare!
end
|
Let me add a reference to this. @JuanitoFatas We can merge this. |
Ping @JuanitoFatas. 😘 |
When you need to map the result of a block invoked a fixed amount of times, you have an option between:
and:
The latter one is about 60% slower for
n = 10
, which goes down to around 40% forn > 1_000.
Note: logarithmic scale!