Re: Optimising #include creation of FastWriter

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.

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

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

eric

On Mar 8, 2006, at 7:32 AM, Alex Twisleton-Wykeham-Fiennes wrote:

> All,
>
> following on from my earlier optimising of Thread shutdowns inside  
> webmacro,
> I've been doing a bit of actual CPU profiling of the running  
> application and
> I found that a significant percentage of processor time was spent  
> creating
> new FastWriter objects as part of the
> Template.evaluateAsBytes(String,Context) method invoked from the
> IncludeDirective.write(FastWriter,Context).
>
> I couldn't see any reason why you should need to create a new  
> FastWriter just
> to write the template into it, convert it to a byte array and then  
> write it
> into the outer FastWriter - especially as the inner FastWriter is  
> only used
> for the duration of the evaluateAsBytes method and is initialised  
> using the
> same encoding as the outer FastWriter.
>
> I therefore made the following changes as an experiment:-
>
> Added:-
> public interface Template {
>   public void write(FastWriter out, Context context)
>     throws PropertyException, IOException;
> }
>
> changed:-
> public class IncludeDirective {
>   public void write(FastWriter out, Context context)
>     throws PropertyExcception, IOException
>   {
>     <snip>
>     case TYPE_TEMPLATE:
>       out.write(((Template) toInclude).evaluateAsBytes 
> (out.getEncoding(),
>                 context));
>     <snip>
>   }
> }
> to:-
> public class IncludeDirective {
>   public void write(FastWriter out, Context context)
>     throws PropertyExcception, IOException
>   {
>     <snip>
>     case TYPE_TEMPLATE:
>       ((Template) toInclude).write(out, context);
>     <snip>
>   }
> }
>
>
> which has yielded a considerable performance increase in the #include
> approach, not to mention a much happier garbage collector (not  
> having to
> allocate a char[512] every time that you include a template).
>
> Are there any major gotcha's in this approach that I haven't  
> spotted, and is
> it worth trying to look through the rest of the code at FastWriter  
> creation
> and try and move it more towards a "streaming" style of model with  
> a single
> FastWriter passed down through the items which is written to  
> directly rather
> than a tree of FastWriters that bubble up their byte[] outputs?
>
> Alex
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Webmacro-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/webmacro-user



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642