Feature #12931
closedAdd support for Binding#instance_eval
Description
Many people would probably like to use binding.instance_eval
when executing templates. The reason for this is because binding.eval
is slow.
The use case is template rendering, e.g. systems like ERB.
In my template renderer, I did have
if Binding === scope
# Slow code path, evaluate the code string in the given binding (scope).
scope.eval(code, @buffer.path)
else
# Faster code path, use instance_eval on a compiled Proc.
scope.instance_eval(&to_proc)
end
The binding path is several orders of magnitude slower because the code is a string and must be parsed, compiled, etc. But, to_proc
path can be cached.
In terms of duck typing, it would be nice if binding implemented #instance_eval
and would allow passing a block.
Updated by nobu (Nobuyoshi Nakada) almost 7 years ago
- Description updated (diff)
Since local variables and constants depend on the context, it won't be able to be "cached," as a Proc
compiled other place.
So I think it isn't worth.
Updated by ioquatix (Samuel Williams) almost 7 years ago
Nobuyoshi Nakada wrote:
Since local variables and constants depend on the context, it won't be able to be "cached," as a
Proc
compiled other place.
So I think it isn't worth.
That makes sense.
So, to clarify, you are saying that there is no way to reuse the compiled proc? It would need to be recompiled?
From my POV, I guess the benefit of this is duck typing.
If performance was the same of eval, it would be acceptable, but if there is some way it could be better, that would be awesome.
Updated by nobu (Nobuyoshi Nakada) over 6 years ago
Correct, there is no way to reuse the compiled proc.
Updated by nobu (Nobuyoshi Nakada) over 6 years ago
- Status changed from Open to Rejected