elasticsearch-ruby

Benchmark#bmbm

Sometimes benchmark results are skewed because code executed
earlier encounters different garbage collection overheads than
that run later. #bmbm attempts to minimize this effect by running
the tests twice, the first time as a rehearsal in order to get the
runtime environment stable, the second time for
real. GC.start is executed before the start of each of
the real timings; the cost of this is not included in the
timings. In reality, though, there's only so much that #bmbm can
do, and the results are not guaranteed to be isolated from garbage
collection and other effects.

Because #bmbm takes two passes through the tests, it can
calculate the required label width.

      require 'benchmark'

      array = (1..1000000).map { rand }

      Benchmark.bmbm do |x|
        x.report("sort!") { array.dup.sort! }
        x.report("sort")  { array.dup.sort  }
      end

Generates:

       Rehearsal -----------------------------------------
       sort!   1.440000   0.010000   1.450000 (  1.446833)
       sort    1.440000   0.000000   1.440000 (  1.448257)
       -------------------------------- total: 2.890000sec

                   user     system      total        real
       sort!   1.460000   0.000000   1.460000 (  1.458065)
       sort    1.450000   0.000000   1.450000 (  1.455963)

#bmbm yields a Benchmark::Job object and returns an array of
Benchmark::Tms objects.

Source | Google | Stack overflow