Skip to content

Instantly share code, notes, and snippets.

@evanphx
Created April 10, 2011 23:24
Show Gist options
  • Save evanphx/912835 to your computer and use it in GitHub Desktop.
Save evanphx/912835 to your computer and use it in GitHub Desktop.
1. benchmark
kendall :: git/rbx » ruby scratch/bm_either.rb
Rehearsal ---------------------------------------------
includes? 4.410000 0.000000 4.410000 ( 4.421223)
either? 6.450000 0.000000 6.450000 ( 6.478906)
compare 2.040000 0.010000 2.050000 ( 2.044516)
----------------------------------- total: 12.910000sec
user system total real
includes? 4.470000 0.000000 4.470000 ( 4.479386)
either? 6.520000 0.000000 6.520000 ( 6.542424)
compare 2.050000 0.010000 2.060000 ( 2.061919)
require 'benchmark'
class Object
def either?(*args)
args.include? self
end
end
count = 10000000
Benchmark.bmbm do |x|
x.report "includes?" do
count.times do
[:one, :two].include?(:one)
end
end
x.report "either?" do
count.times do
:one.either?(:one, :two)
end
end
x.report "compare" do
count.times do
:one == :one or :one == :two
end
end
end
@dhh
Copy link

dhh commented Apr 11, 2011

Same test on Ruby 1.9.2 and added in? as well:

$ ruby ~/Desktop/inc.rb
Rehearsal ---------------------------------------------
includes? 1.400000 0.000000 1.400000 ( 1.400703)
either? 1.800000 0.010000 1.810000 ( 1.793301)
in? 1.730000 0.000000 1.730000 ( 1.733053)
compare 0.850000 0.000000 0.850000 ( 0.845583)
------------------------------------ total: 5.790000sec

            user     system      total        real

includes? 1.390000 0.000000 1.390000 ( 1.396793)
either? 1.790000 0.000000 1.790000 ( 1.788230)
in? 1.730000 0.000000 1.730000 ( 1.729842)
compare 0.850000 0.000000 0.850000 ( 0.849059)

So either? is just 28% slower and in? is just 23% slower on 1.9.2. That seems completely negligible unless this check somehow sits in an already insanely optimized hot spot area.

@evanphx
Copy link
Author

evanphx commented Apr 11, 2011

Totally true, the difference on 1.9 is less (though still over 2x). But I figured 1.8 was the optimization target, since it is the most common denominator and that's where most of the existing users are.

@dhh
Copy link

dhh commented Apr 11, 2011

Where are you seeing the 2x? I'm seeing 23% and 28% respectively. Also, from Rails 3.1 forward, I consider Ruby 1.9 to be the primary Ruby and the 1.8 to just be a legacy option we continue to support until Rails 4.

@evanphx
Copy link
Author

evanphx commented Apr 11, 2011

0.85 vs. 1.73 is where I was indicating the 2x.

@dhh
Copy link

dhh commented Apr 11, 2011

includes? runs in 1.4s and either? runs in 1.8s. in? runs in 1.73s.

@evanphx
Copy link
Author

evanphx commented Apr 11, 2011

Yep, totally true. Part of my original point was to challenge the idea that #include? is itself a good idea and that direct comparison should be considered if there are only 2 elements being compared with.

@dhh
Copy link

dhh commented Apr 11, 2011

Ah, I see what you mean. You consider even include? to be too slow :). But yeah, if we have anything like that in a hot spot flow, we can totally replace it with direct comparison. I'd consider that to be a pretty extreme perf optimization that I'd want solid evidence for making a big difference.

Thanks for adding some stats to the discussion, though. It's great that we now know that it's 23%/28% slower than include? and that inlining direct comparison can save you double up.

@evanphx
Copy link
Author

evanphx commented Apr 11, 2011 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment