Nathan Bubna wrote:
On Wed, Oct 1, 2008 at 10:40 AM, Byron Foster <[EMAIL PROTECTED]> wrote:
I was considering the possibility that references within macros
could be optimized. Given the following:
#macro(foo $a $b) $a $b #end
#foo($c $d.e)
Currently both $a $b within the macro are referenced by AST.
However, with some compile time analysis it can be determined that
$a and $b can be referenced directly from the macro context (just
like variables outside of a macro). The analysis can determine
that $c and $d are not modified during the macro call by walking
the AST tree and insuring these references do not exist within the
macro.
interesting. any idea what sort of gains this effort would provide
in your simple example? since this wouldn't be a simple
optimization, it would be important to see how performance really
changes in one or two cases.
It's a little hard to tell with the profiler. But, it may not save that
much time. With simple single variables you have already optimized it so
that it is reduced to a couple of context lookups. One way would be to
implement a prototype and implement. But, probably not anytime soon :)
Not only could the AST be removed, but the value $d.e could be
passed in to $b which would avoid looking up the 'e' property on $d
every time $b is referenced. This would also save memory since the
AST nodes for all the references in the macro could be removed.
Anyone see a problem with this?
yeah, that would be a showstopper, as that would be pass by value,
which is a drastic change. we can't verify that $d.e will always
return the same value. you can't even cache the value returned by
rendering $d, since the value returned by $d.toString() can change on
subsequent calls. VelocityTools' Alternator relies upon this.
Yea, that would be a problem if there are side effects from method calls
:). You can test if there are any changes to $d like #set($d = $newobj)
but that doesn't fix something like the Alternator, even though I doubt
You pass the Alternator object in like #go($d.toString()). But a problem
none the less.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
