Possible macro optimization

[Byron Foster <by...@base2.cc>]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: Possible macro optimization

[Nathan Bubna <nb...@gmail.com>]

On Mon, Oct 6, 2008 at 10:02 PM, Byron Foster <by...@base2.cc> wrote:
>
>
> Nathan Bubna wrote:
>>
>> On Wed, Oct 1, 2008 at 10:40 AM, Byron Foster <by...@base2.cc> 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 :)

Well, let us know if you take a stab at it, and don't be shy about
opening a JIRA issue if you want to keep the idea out there.

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

yep. :)

>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: Possible macro optimization

[Byron Foster <by...@base2.cc>]

Nathan Bubna wrote:
> On Wed, Oct 1, 2008 at 10:40 AM, Byron Foster <by...@base2.cc> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: Possible macro optimization

[Nathan Bubna <nb...@gmail.com>]

On Wed, Oct 1, 2008 at 10:40 AM, Byron Foster <by...@base2.cc> 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.

> 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: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org