On Mon, Oct 6, 2008 at 10:02 PM, Byron Foster <[EMAIL PROTECTED]> wrote: > > > 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 :)
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
