[WebMacro-user] Optimising #include creation of FastWriter

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

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