Optimising #include creation of FastWriter

Alex Twisleton-Wykeham-Fiennes <[email protected]> Wed, 8 Mar 2006 12:32:44 +0000
Newsgroups gmane.comp.java.webmacro.user
Message-ID <[email protected]>
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