Yield or call?

Yes, but not in the helper method. In the code I’ve shown there’s
always a block passed to the helper method. Phlip has a point here.

That’s very easy to solve:

What about the two kinds of performance? Programmer performance and
program performance?

This permits only one (DRY) call to y:

  y { yield if block_given? }

So is it performant? Note someone here asserted that yield was faster,
so are these constructions still faster than a brute-force ‘block.call
if block’ ?

When I see ‘if block’ I think of comparing the RVALUE type field to
nil or false. Just a bit mask.

On 8/6/07, Phlip [email protected] wrote:

Ronald F. wrote:

Is there a principal reason when to prefer call over yield (or vice
versa), or are these only syntactic variations of the same feature?

I am learning to consider ‘yield’ as a fossil of an early Ruby that could
not treat the bound block as a variable. I only use ‘yield’ as a slight
convenience - a few less characters to type - in application-specific code.
Do not do this, yield suffers a lot from a bad reputation it does not
deserve, see also David’s benchmarks above.

When writing API-style code, I always start with &block because it’s only a
matter of time before I refactor the code and start passing that &block into
a helper method.
Why? I do not think that this is necessary.
Just replace the refactoring
old: yield ==> something &blk + changing the def
with
new: yield ==> something &Proc.new

However I never use yield, but for a completely different reason, I
want my def to show if I yield or not.
In case I am unhappy with performance I can still change back.

Cheers
Robert

I actually wanted to say something about this issue but it seems that
my posts got cut, not sent, whatever, even I have difficulties to
understand the fragments.
Please (1) ignore them, (2) excuse me for the noise and (3) blame gmail
;).

Sorry
Robert

Hi –

On Tue, 7 Aug 2007, Phlip wrote:

  y { yield if block_given? }

So is it performant? Note someone here asserted that yield was faster,
so are these constructions still faster than a brute-force ‘block.call
if block’ ?

When I see ‘if block’ I think of comparing the RVALUE type field to
nil or false. Just a bit mask.

Here are some benchmarks, for the two conditionals with and without a
block:

david-a-blacks-computer:~/hacking dblack$ cat yi.rb
require ‘benchmark’
include Benchmark

def x(&b)
b.call if b
end

def y
yield if block_given?
end

n = 1000000

bmbm do |b|
b.report(“b”) { n.times { x { } } }
b.report(“y”) { n.times { y { } } }
b.report(“b-no block”) { n.times { x } }
b.report(“y-no block”) { n.times { y } }
end
david-a-blacks-computer:~/hacking dblack$ ruby yi.rb
Rehearsal ----------------------------------------------
b 3.780000 0.010000 3.790000 ( 3.798711)
y 0.700000 0.000000 0.700000 ( 0.695756)
b-no block 0.350000 0.000000 0.350000 ( 0.351118)
y-no block 0.380000 0.000000 0.380000 ( 0.390713)
------------------------------------- total: 5.220000sec

              user     system      total        real

b 3.810000 0.000000 3.810000 ( 3.846940)
y 0.700000 0.010000 0.710000 ( 0.760668)
b-no block 0.350000 0.000000 0.350000 ( 0.353762)
y-no block 0.390000 0.000000 0.390000 ( 0.390436)

So if the test is negative, there’s not a huge difference; the
difference mainly comes when there is a block.

David