7

I have a ruby method that needs to check if a block was passed to it. A colleague is suggesting that simply checking if block.nil? is slightly faster in performance and works for named blocks. This is already quite annoying since he is using the named block and invoking it using block.call rather than yield which has been shown to be significantly faster, since named blocks are more easy to understand in terms of readability.

Version 1:

def named_block &block
   if block.nil?
     puts "No block"
   else
     block.call
   end
end

Version 2:

def named_block &block
  if !block_given?
    puts "No block"
  else 
    block.call
  end
end

Benchmarking shows that version 1 is slightly faster than version 2, however a quick look at the source code seems to suggest that block_given? is thread safe.

What are the main differences between the two approaches? Please help me prove him wrong!

singletony
  • 1,392
  • 1
  • 9
  • 9
  • 5
    What you are doing is called **“premature optimization.”** The productivity bottleneck _is never related to ruby internals_. So pick up any variant of your choice and go with it. – Aleksei Matiushkin Nov 23 '16 at 10:42
  • 1
    Also, `yield` might be perfectly used when named block is given instead of explicit `block.call`. – Aleksei Matiushkin Nov 23 '16 at 10:45
  • 1
    @mudasobwa It's still good to know the tradeoffs between implementations. Me & singletony work together on our company's infrastructure. We don't specifically care about the performance of each implementation but on the tradeoffs of each implementation. – the_drow Nov 23 '16 at 10:56
  • @the_drow in Layman’s terms the answer is “there are no tradeoffs; pick up any approach and make sure it’s usage is consistent across the company.” `if !block_given?` negation under two-branched `if`, appeared in the OP, is waaaay worse, than `cb.nil?` vs `block_given?`. – Aleksei Matiushkin Nov 23 '16 at 11:00
  • @mudasobwa actually the invocation in our code is `block.call unless block.nil?` vs `block.call if block_given?`, so my post is a variation and I agree it wasn't the best one. That said, I agree with @the_drow, we care about the tradeoffs (and proving I am right) and some of the answers here address those well. – singletony Nov 23 '16 at 12:19

3 Answers3

7

First off, while a single nil? check might be faster than block_given?, capturing the block is slow. So unless you were going to capture it anyway, the performance argument is invalid.

Secondly, it's easier to understand. Whenever you see block_given?, you know exactly what is up. When you have x.nil?, you have to stop and think what x is.

Thirdly, it's an idiom. In my experience, the overwhelming majority of Ruby developers will prefer block_given?. When in Rome...

Lastly, you can keep it consistent. If you always use block_given? the problem is solved for you. If you use nil? checks, you have to have the block captured.

  • There is a performance overhead.
  • It's more verbose, something Rubyists try to avoid.
  • Naming things is one of the hardest things in programming. :) Can you think of a good name for the block Enumerable#map will get for example?
  • "Grepability" is a desirable trait for a codebase to have. If you want to find all the places where you check if you were given a block, doing nil? checks can prove difficult.
ndnenkov
  • 35,425
  • 9
  • 72
  • 104
  • @the_drow what about reading ruby documentation on the subject? I voted for the question to be closed as “primarily opinion based,” and I suggest everybody here to do so. – Aleksei Matiushkin Nov 23 '16 at 11:01
  • 2
    @the_drow, procs are immutable. Also I haven't checked the implementation, but my guess is that a `nil?` check is atomic. So I don't think it makes a difference either way. – ndnenkov Nov 23 '16 at 11:06
0

I think that the main difference is that block_given? can be used without explicitly defining &block in method definition:

def named_block
  if !block_given?
    puts "No block"
  else 
    yield
  end
end

Which version is better when it goes for readability? Sometimes explicitly naming the block can be more readable and sometimes yield can be more readable. It's also mater of personal preferences.

When it goes to speed, in benchmarks, that you've included, the yield is faster. That is because Ruby doesen't have to initialize new object (Proc) for the block and assign it to variable.

maicher
  • 2,625
  • 2
  • 16
  • 27
0

There is another way to accomplish this:

def named_block
   (Proc.new rescue puts("No block") || ->{}).call
end

▶ named_block
#⇒ No block
▶ named_block { puts 'BLOCK!' }
#⇒ BLOCK!

please don’t take this too seriously

UPD: as noted by @Lukas in comments, it fails on the block, that raises an exception ⇒ FIXED

Aleksei Matiushkin
  • 119,336
  • 10
  • 100
  • 160