blocks - ruby pass block as argument

Ruby: Proc#call vs yield

Question

¿Cuáles son las diferencias de comportamiento entre las dos implementaciones siguientes en el método Ruby of the thrice ?

module WithYield
  def self.thrice
    3.times { yield }      # yield to the implicit block argument
  end
end

module WithProcCall
  def self.thrice(&block)  # & converts implicit block to an explicit, named Proc
    3.times { block.call } # invoke Proc#call
  end
end

WithYield::thrice { puts "Hello world" }
WithProcCall::thrice { puts "Hello world" }

Por "diferencias de comportamiento" incluyo manejo de errores, rendimiento, soporte de herramientas, etc.

Answer 1

Aquí hay una actualización para Ruby 2.x

ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.3.0]

Me cansé de escribir puntos de referencia manualmente, así que creé un pequeño módulo de corredor llamado benchable

require ''benchable'' # https://gist.github.com/naomik/6012505

class YieldCallProc
  include Benchable

  def initialize
    @count = 10000000    
  end

  def bench_yield
    @count.times { yield }
  end

  def bench_call &block
    @count.times { block.call }
  end

  def bench_proc &block
    @count.times &block
  end

end

YieldCallProc.new.benchmark

Salida

                      user     system      total        real
bench_yield       0.930000   0.000000   0.930000 (  0.928682)
bench_call        1.650000   0.000000   1.650000 (  1.652934)
bench_proc        0.570000   0.010000   0.580000 (  0.578605)

Creo que lo más sorprendente aquí es que bench_yield es más lento que bench_proc . Desearía tener un poco más de comprensión sobre por qué sucede esto.

Answer 2

Creo que el primero es en realidad un azúcar sintáctico del otro. En otras palabras, no hay diferencia de comportamiento.

Sin embargo, lo que permite la segunda forma es "guardar" el bloque en una variable. Luego se puede llamar al bloque en algún otro punto en el tiempo: devolución de llamada.

De acuerdo. Esta vez fui e hice un punto de referencia rápido:

require ''benchmark''

class A
  def test
    10.times do
      yield
    end
  end
end

class B
  def test(&block)
    10.times do
      block.call
    end
  end
end

Benchmark.bm do |b|
  b.report do
    a = A.new
    10000.times do
      a.test{ 1 + 1 }
    end
  end

  b.report do
    a = B.new
    10000.times do
      a.test{ 1 + 1 }
    end
  end

  b.report do
    a = A.new
    100000.times do
      a.test{ 1 + 1 }
    end
  end

  b.report do
    a = B.new
    100000.times do
      a.test{ 1 + 1 }
    end
  end

end

Los resultados son interesantes:

      user     system      total        real
  0.090000   0.040000   0.130000 (  0.141529)
  0.180000   0.060000   0.240000 (  0.234289)
  0.950000   0.370000   1.320000 (  1.359902)
  1.810000   0.570000   2.380000 (  2.430991)

Esto muestra que usar block.call es casi 2 veces más lento que usar yield .

Answer 3

Dan diferentes mensajes de error si olvida pasar un bloque:

> WithYield::thrice
LocalJumpError: no block given
        from (irb):3:in `thrice''
        from (irb):3:in `times''
        from (irb):3:in `thrice''

> WithProcCall::thrice
NoMethodError: undefined method `call'' for nil:NilClass
        from (irb):9:in `thrice''
        from (irb):9:in `times''
        from (irb):9:in `thrice''

Pero se comportan igual si intentas pasar un argumento "normal" (sin bloque):

> WithYield::thrice(42)
ArgumentError: wrong number of arguments (1 for 0)
        from (irb):19:in `thrice''

> WithProcCall::thrice(42)
ArgumentError: wrong number of arguments (1 for 0)
        from (irb):20:in `thrice''

Answer 4

Descubrí que los resultados son diferentes dependiendo de si fuerza a Ruby a construir el bloque o no (por ejemplo, un proceso preexistente).

require ''benchmark/ips''

puts "Ruby #{RUBY_VERSION} at #{Time.now}"
puts

firstname = ''soundarapandian''
middlename = ''rathinasamy''
lastname = ''arumugam''

def do_call(&block)
    block.call
end

def do_yield(&block)
    yield
end

def do_yield_without_block
    yield
end

existing_block = proc{}

Benchmark.ips do |x|
    x.report("block.call") do |i|
        buffer = String.new

        while (i -= 1) > 0
            do_call(&existing_block)
        end
    end

    x.report("yield with block") do |i|
        buffer = String.new

        while (i -= 1) > 0
            do_yield(&existing_block)
        end
    end

    x.report("yield") do |i|
        buffer = String.new

        while (i -= 1) > 0
            do_yield_without_block(&existing_block)
        end
    end

    x.compare!
end

Da los resultados:

Ruby 2.3.1 at 2016-11-15 23:55:38 +1300

Warming up --------------------------------------
          block.call   266.502k i/100ms
    yield with block   269.487k i/100ms
               yield   262.597k i/100ms
Calculating -------------------------------------
          block.call      8.271M (± 5.4%) i/s -     41.308M in   5.009898s
    yield with block     11.754M (± 4.8%) i/s -     58.748M in   5.011017s
               yield     16.206M (± 5.6%) i/s -     80.880M in   5.008679s

Comparison:
               yield: 16206091.2 i/s
    yield with block: 11753521.0 i/s - 1.38x  slower
          block.call:  8271283.9 i/s - 1.96x  slower

Si cambia do_call(&existing_block) a do_call{} , encontrará que es aproximadamente 5 veces más lento en ambos casos. Creo que la razón de esto debería ser obvia (porque Ruby se ve obligada a construir un Proc para cada invocación).

Answer 5

La diferencia de comportamiento entre los diferentes tipos de cierres de rubí ha sido ampliamente documentada

Answer 6

Las otras respuestas son bastante exhaustivas y Closures in Ruby cubre ampliamente las diferencias funcionales. Tenía curiosidad sobre qué método funcionaría mejor para los métodos que aceptaban un bloque, así que escribí algunos puntos de referencia (saliendo de esta publicación de Paul Mucur ). Comparé tres métodos:

• & bloquear en la firma del método
• Usando &Proc.new
• yield embalaje en otro bloque

Aquí está el código:

require "benchmark"

def always_yield
  yield
end

def sometimes_block(flag, &block)
  if flag && block
    always_yield &block
  end
end

def sometimes_proc_new(flag)
  if flag && block_given?
    always_yield &Proc.new
  end
end

def sometimes_yield(flag)
  if flag && block_given?
    always_yield { yield }
  end
end

a = b = c = 0
n = 1_000_000
Benchmark.bmbm do |x|
  x.report("no &block") do
    n.times do
      sometimes_block(false) { "won''t get used" }
    end
  end
  x.report("no Proc.new") do
    n.times do
      sometimes_proc_new(false) { "won''t get used" }
    end
  end
  x.report("no yield") do
    n.times do
      sometimes_yield(false) { "won''t get used" }
    end
  end

  x.report("&block") do
    n.times do
      sometimes_block(true) { a += 1 }
    end
  end
  x.report("Proc.new") do
    n.times do
      sometimes_proc_new(true) { b += 1 }
    end
  end
  x.report("yield") do
    n.times do
      sometimes_yield(true) { c += 1 }
    end
  end
end

El rendimiento fue similar entre Ruby 2.0.0p247 y 1.9.3p392. Aquí están los resultados para 1.9.3:

                  user     system      total        real
no &block     0.580000   0.030000   0.610000 (  0.609523)
no Proc.new   0.080000   0.000000   0.080000 (  0.076817)
no yield      0.070000   0.000000   0.070000 (  0.077191)
&block        0.660000   0.030000   0.690000 (  0.689446)
Proc.new      0.820000   0.030000   0.850000 (  0.849887)
yield         0.250000   0.000000   0.250000 (  0.249116)

Agregar un parámetro explícito &block cuando no siempre se usa realmente ralentiza el método. Si el bloque es opcional, no lo agregue a la firma del método. Y, para pasar bloques, el yield envolver en otro bloque es el más rápido.

Dicho esto, estos son los resultados de un millón de iteraciones, así que no te preocupes demasiado por eso. Si un método hace que su código sea más claro a expensas de una millonésima de segundo, úselo de todos modos.

Answer 7

Por cierto, solo para actualizar esto al día actual usando:

ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]

En Intel i7 (1.5 años de edad).

user     system      total        real
0.010000   0.000000   0.010000 (  0.015555)
0.030000   0.000000   0.030000 (  0.024416)
0.120000   0.000000   0.120000 (  0.121450)
0.240000   0.000000   0.240000 (  0.239760)

Aún 2 veces más lento. Interesante.