From: Dave Cantrell <ruby-talk@...>
Date: 2006-02-16T04:01:04+09:00
Subject: Re: Rescuing blocks?

Daniel Nugent wrote:
> Pat: I think it already does and there's still a performance hit. 
> Though Eric's machine chugs a little more than mine, I'd be interested
> to see what his ratios are with this added benchmark:
> 
> require 'benchmark'
> 
> N = 10_000_000
> 
> Benchmark.bmbm do |b|
>   b.report 'begin' do
>     N.times { begin; rescue; end }
>   end
> 
>   b.report 'begin no rescue' do
>     N.times { begin; end }
>   end
> 
>   b.report 'no begin' do
>     N.times { }
>   end
> end

On my machine, WinXP Home SP2, 512mb RAM, Athlon 1900 (or so). Both 
benchmarks run within irb.

Using Eric's original code:

Rehearsal --------------------------------------------
begin      3.578000   0.000000   3.578000 (  3.625000)
no begin   1.782000   0.000000   1.782000 (  1.828000)
----------------------------------- total: 5.360000sec

                user     system      total        real
begin      3.547000   0.000000   3.547000 (  3.625000)
no begin   1.796000   0.000000   1.796000 (  1.812000)

100% increase between the two. Not as much as Eric's, but still 
significant I would think.

Using Daniel's code:

Rehearsal ---------------------------------------------------
begin             3.546000   0.000000   3.546000 (  3.625000)
begin no rescue   2.829000   0.000000   2.829000 (  2.875000)
no begin          1.781000   0.000000   1.781000 (  1.828000)
------------------------------------------ total: 8.156000sec

                       user     system      total        real
begin             3.547000   0.000000   3.547000 (  3.609000)
begin no rescue   2.812000   0.000000   2.812000 (  2.891000)
no begin          1.735000   0.000000   1.735000 (  1.797000)


Interesting middle ground there. So begin/end blocks have their own 
overhead, above and beyond the exception handlers.

Note that I am not a benchmarking expert, and in fact am merely guessing 
at the relative importance of the numbers, assuming the "real" values 
are the important ones. I probably should read more about this module.