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. > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
