velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Byron Foster <>
Subject Re: Possible macro optimization
Date Tue, 07 Oct 2008 05:02:55 GMT

Nathan Bubna wrote:
> 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 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:
For additional commands, e-mail:

View raw message