velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <>
Subject Re: Possible macro optimization
Date Wed, 01 Oct 2008 19:31:59 GMT
On Wed, Oct 1, 2008 at 10:40 AM, Byron Foster <> 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

> 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.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message