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

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.

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

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

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 // evan@fallingsnow.net

…

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