From: Chris White <cwprogram@...>
Date: 2011-08-09T12:41:59+09:00
Subject: Re: Methods defined with module_eval are... faster?


On Aug 7, 2011, at 5:45 AM, Iņaki Baz Castillo wrote:

> Hi, just let me show this code:
> 
> -------------------
> require "benchmark"
> 
> 
> module M
>  self.module_eval("
>    def self.kk(var)
>      if var == 123
>        a=var*2
>      else
>        a=var*4
>      end
>    end
> ")
> 
>  def self.aa(var)
>    if var == 123
>      b=var*2
>    else
>      b=var*4
>    end
>  end
> end
> 
> 
> printf "M.kk: "
> puts Benchmark.realtime { 4000000.times { M.kk(123) ; M.kk(4) } }
> printf "M.aa: "
> puts Benchmark.realtime { 4000000.times { M.aa(123) ; M.aa(4) } }
> printf "M.kk: "
> puts Benchmark.realtime { 4000000.times { M.kk(123) ; M.kk(4) } }
> printf "M.aa: "
> puts Benchmark.realtime { 4000000.times { M.aa(123) ; M.aa(4) } }
> -------------------
> 
> 
> Results (ruby 1.9.2):
> 
> M.kk: 1.4799699783325195
> M.aa: 1.6037561893463135
> M.kk: 1.4918322563171387
> M.aa: 1.612684965133667


Okay so I took another look at this. Since the bytecode I showed before only showed the string of code being sent to module_eval, I needed to find a way to get the bytecode for the result of running it. Fortunately in vm_eval.c there's a line that's set to `if (0)`, where the code it's surrounding shows the resulting eval bytecode (with a comment saying use it for debug purposes only, which, guess what I'm doing!) Horray, so I  set this to 1, recompiled and this is what I got:

https://gist.github.com/1133353

Line for line, it's all exactly the same (okay with the exception of variable names). This breaks my theory that eval's behind the scenes generation did something unique with the code. Here's my results running it on Mac OSX 1.9.2-p290 source compile:

M.kk: 1.056156873703003
M.aa: 1.0313341617584229
M.kk: 1.0313379764556885
M.aa: 1.0262627601623535

In this case there's less and less of a difference. I'd almost go so far to say that it's just slight inaccuracies involved in benchmark timings, with the bytecode being the same and all. 

Regards,
Chris White
http://www.twitter.com/cwgem