velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <nbu...@gmail.com>
Subject Re: Possible macro optimization
Date Tue, 07 Oct 2008 14:22:27 GMT
On Mon, Oct 6, 2008 at 10:02 PM, Byron Foster <byron@base2.cc> wrote:
>
>
> Nathan Bubna wrote:
>>
>> On Wed, Oct 1, 2008 at 10:40 AM, Byron Foster <byron@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


Mime
View raw message