From: Nathan Weizenbaum <nex342@...>
Date: 2008-04-23T09:20:17+09:00
Subject: Re: Performance on method dispatch for methods defined via define_method

It really isn't possible to statically determine whether eval is called 
in a given block, because it's possible that any given function may be 
aliased to eval - even after the function is compiled. For example, 
consider the following harmless code snippet:

  class Foo
    foo = 12
    define_method(:bar) { puts "foo" }
  end

Perfectly harmless, right? Well, not if I do this:

  class Foo
    alias_method :puts, :eval
  end

Now Foo.new.bar returns 12. In fact, any method could become a call to eval.

- Nathan

Robert Dober wrote:
> On Wed, Apr 23, 2008 at 12:48 AM, David A. Black <dblack@rubypal.com> wrote:
>
>   
>>   define_method(:c) { puts send([101, 118, 97, 108].pack("C*"),
>>   gets.chomp) }
>>
>>  :-)
>>
>>  I don't know... it seems to me that determining statically whether or
>>  not a block will refer back to its context would be really, really
>>  difficult, at the very least.
>>     
>
> Not at all, David, at least not from your examples, it might follow
> this simple strategy
> Whenever a reference to the closure is made, --> return :do_not_inline
> Whenever metaprogramming like eval or send is done
>     can I determine the parameters of send/eval e.g. simple literals
> --> evaluate them and react accordingly
>     else --> return :do_not_inline
> return --> :inline
>
> It goes without saying that your examples will not be inlined
> allthough evaluating
> send([101, 118, 97, 108].pack("C*").gets.chomp
> could be done it surely is not worth it.
>
> In other words the attempt to inline a define_method block into a def
> would follow an early failure strategy.
>
> I give you an example:
>
> trait {
>    behavior :a do 42 end
> }
> when define_method is called with the block above a very simple and
> defensive and fast check would still bring 50% performance gain for
> the invocations of a.
>
> Maybe the check can even be done against the bytecode, but I do not
> know when the block above is compiled.
>
> Now this is not a feature request but a request to learn more about
> the feasibility.
>
> Robert
>
>
>
>