Re: [WebMacro-user] Optimising #include creation of FastWriter

[Alex Twisleton-Wykeham-F. <al...@fi...>]

On Wed 8 March 2006 17:58, Eric B. Ridge wrote:
> I've been thinking back to when I write IncludeDirective and I simply
> cannot remember why it makes a new FastWriter.  Was it because the
> old ParseDirective did that and I was just coping it?  Was it out of
> sheer stupidity?  Or maybe some reason about not wanting to muck with
> the real FastWriter in the event of a parsing/evaluation exception.
> I dunno.

The only reason for the exception handling being an issue would be if you were 
going to be doing some kind of intelligent rollback on your nested template 
evaluation.  However, this doesn't smell write from an encapsulation point of 
view as I would expect any calculations that had rollbacks would take place 
in java space before you handed over control to the webmacro template, but if 
anyone has any real world situations that this would break then let me know.

> At any rate, I can't think of a reason why your idea won't work.  So
> I say go for it.

OK.  I'll get the destroy() stuff out of the way first and then have a closer 
look at the whole streaming thing...

> Go for the #eval thing too.  I know #setblock uses the same pattern,
> but it might actually be necessary for #setblock to do this.

I think that it is probably worth it.  On a relatively trivial application 
that was doing a fair amount of nested including and evaluating of templates, 
OptimizeIt was reporting that roughly 10 - 15 % of time was spent purely in 
creating FastWriters which just feels wrong to me...

I'll have a sweep through the entire tree looking for the usage patterns of 
FastWriter and will see if there are any other points that look like they 
should be tweaked as well.

Alex