Llamada a un método dinámico en Ruby

metaprogramming dynamic-method

Question

Por lo que sé, hay tres formas de llamar dinámicamente un método en Ruby:

Método 1:

s = SomeObject.new
method = s.method(:dynamic_method)
method.call

Método 2:

s = SomeObject.new
s.send(:dynamic_method)

Método 3:

s = SomeObject.new
eval "s.dynamic_method"

Al compararlos, he establecido que el Método 1 es, con mucho, el más rápido, el Método 2 es más lento y el Método 3 es con mucho el más lento.

También encontré que .call y .send permiten llamar a métodos privados, mientras que eval no.

Entonces mi pregunta es: ¿hay alguna razón para usar .send o eval ? ¿Por qué no siempre usarías el método más rápido? ¿Qué otras diferencias tienen estos métodos para llamar a los métodos dinámicos?

Answer 1

¿Hay alguna razón para usar send ?

call necesita un objeto de método, el send no:

class Foo
  def method_missing(name)
    "#{name} called"
  end
end

Foo.new.send(:bar)         #=> "bar called"
Foo.new.method(:bar).call  #=> undefined method `bar'' for class `Foo'' (NameError)

¿Hay alguna razón para usar alguna vez eval ?

eval evalúa expresiones arbitrarias, no es solo para llamar a un método.

En cuanto a los puntos de referencia, el send parece ser más rápido que el method + call :

require ''benchmark''

class Foo
  def bar; end
end

Benchmark.bm(4) do |b|
  b.report("send") { 1_000_000.times { Foo.new.send(:bar) } }
  b.report("call") { 1_000_000.times { Foo.new.method(:bar).call } }
end

Resultado:

           user     system      total        real
send   0.210000   0.000000   0.210000 (  0.215181)
call   0.740000   0.000000   0.740000 (  0.739262)

Answer 2

Actualicé el punto de referencia de @Stefan para verificar si hay algunas mejoras de velocidad al guardar la referencia al método. Pero de nuevo, send es mucho más rápido que call

require ''benchmark''

class Foo
  def bar; end
end

foo = Foo.new
foo_bar = foo.method(:bar)

Benchmark.bm(4) do |b|
  b.report("send") { 1_000_000.times { foo.send(:bar) } }
  b.report("call") { 1_000_000.times { foo_bar.call } }
end

Estos son los resultados:

           user     system      total        real
send   0.080000   0.000000   0.080000 (  0.088685)
call   0.110000   0.000000   0.110000 (  0.108249)

Así que send parece ser el que tomar.

Answer 3

Aquí están todas las llamadas a métodos posibles:

require ''benchmark/ips''

class FooBar
  def name; end
end

el = FooBar.new

Benchmark.ips do |x|
  x.report(''plain'') { el.name }
  x.report(''eval'') { eval(''el.name'') }
  x.report(''method call'') { el.method(:name).call }
  x.report(''send sym'') { el.send(:name) }
  x.report(''send str'') { el.send(''name'') }
  x.compare!
end

Y los resultados son:

Warming up --------------------------------------
               plain   236.448k i/100ms
                eval    20.743k i/100ms
         method call   131.408k i/100ms
            send sym   205.491k i/100ms
            send str   168.137k i/100ms
Calculating -------------------------------------
               plain      9.150M (± 6.5%) i/s -     45.634M in   5.009566s
                eval    232.303k (± 5.4%) i/s -      1.162M in   5.015430s
         method call      2.602M (± 4.5%) i/s -     13.009M in   5.010535s
            send sym      6.729M (± 8.6%) i/s -     33.495M in   5.016481s
            send str      4.027M (± 5.7%) i/s -     20.176M in   5.027409s

Comparison:
               plain:  9149514.0 i/s
            send sym:  6729490.1 i/s - 1.36x  slower
            send str:  4026672.4 i/s - 2.27x  slower
         method call:  2601777.5 i/s - 3.52x  slower
                eval:   232302.6 i/s - 39.39x  slower

Se espera que la llamada simple sea la más rápida, sin asignaciones adicionales, búsquedas de símbolos, solo búsqueda y evaluación del método.

En cuanto a send través de un símbolo, es más rápido que a través de una cadena ya que es mucho más fácil asignar memoria para el símbolo. Una vez que está definido, se almacena a largo plazo en la memoria y no hay reasignaciones.

La misma razón se puede decir sobre el method(:name) (1) es necesario asignar memoria para el objeto Proc (2) estamos llamando al método en la clase que conduce a la búsqueda de métodos adicionales, que también lleva tiempo.

eval se ejecuta intérprete por lo que es el más pesado.

Answer 4

El objetivo de send y eval es que puedes cambiar el comando de forma dinámica. Si el método que desea ejecutar es fijo, entonces puede cablear ese método sin utilizar send o eval .

receiver.fixed_method(argument)

Pero cuando desea invocar un método que varía o no sabe de antemano, no puede escribirlo directamente. De ahí el uso de send o eval .

receiver.send(method_that_changes_dynamically, argument)
eval "#{code_to_evaluate_that_changes_more_dramatically}"

El uso adicional de send es que, como habrás notado, puedes llamar a un método con un receptor explícito usando send .

Answer 5

Piénsalo de esta manera:

Método 1 (method.call): Single run-time

Si ejecuta Ruby una vez en su programa directamente, usted controla todo el sistema y puede mantener un "puntero a su método" a través del método "method.call". Todo lo que está haciendo es mantener un identificador de "código en vivo" que puede ejecutar cuando lo desee. Esto es básicamente tan rápido como llamar al método directamente desde el objeto (pero no es tan rápido como usar object.send - ver benchmarks en otras respuestas).

Método 2 (object.send): persistir el nombre del método en la base de datos

Pero, ¿qué ocurre si desea almacenar el nombre del método que desea llamar en una base de datos y, en una aplicación futura, desea llamar al nombre de ese método buscándolo en la base de datos? Luego usaría el segundo enfoque, que hace que Ruby llame a un nombre de método arbitrario usando su segundo enfoque "s.send (: dynamic_method)".

Método 3 (eval): código de método de auto modificación

¿Qué sucede si quiere escribir / modificar / persistir el código en una base de datos de una manera que ejecute el método como un código nuevo? Puede modificar periódicamente el código escrito en la base de datos y querer que se ejecute como código nuevo cada vez. En este (caso muy inusual), querrá utilizar su tercer enfoque, que le permite escribir su código de método como una cadena, cargarlo de nuevo en una fecha posterior y ejecutarlo en su totalidad.

Por lo que vale, generalmente se considera en el mundo de Ruby como una forma mala de usar Eval (método 3) excepto en casos muy, muy esotéricos y raros. Por lo tanto, debe seguir con los métodos 1 y 2 para casi todos los problemas que encuentre.