1. benchmark

2. ruby 1.8

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)

gistfile1.txt

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

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.

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.

No problem, having the data always helps, no matter what the decision is. ## Evan Phoenix // [email protected]

…

On Monday, April 11, 2011 at 9:48 AM, dhh wrote: 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. ## Reply to this email directly or view it on GitHub: https://gist.github.com/912835