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

Brought to you by: alexfiennes, briangoetz, drater, guyboltonking, and 4 others

webmacro-user

[WebMacro-user] Optimising #include creation of FastWriter

From: Alex Twisleton-Wykeham-F. <al...@fi...> - 2006-03-08 12:32:16

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

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

From: Alex Twisleton-Wykeham-F. <al...@fi...> - 2006-03-08 13:21:18

On Wed 8 March 2006 12:32, 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've found a similar situation inside the EvalDirective that was creating 
FastWriters for each level of Eval.  Therefore a self-recursive #eval 
statement (such as discussed on the list recently) would generate a char[512] 
for every time it recursed which would all then be flattened down onto the 
parent one and eventually written out onto the original FastWriter.

I patched this as well to pass the master FastWriter down the chain, and it 
does indeed give a major performance increase (assuming that your templating 
structure uses a fair amount of #eval) (summary of patch at end of email).

The only point of concern for me about this is what happens to the state of 
the master FastWriter if the process fails at some point down the line.  In 
the default model, the PropertyException is thrown and the content of the 
FastWriter is not required and an error template is returned.  However, there 
may be situations when the PropertyException is caught and handled 
differently.  In this case, the master FastWriter would contain data up to 
the point when the PropertyException was thrown, whereas the previous model 
would contain data up to the start of the block which triggered the 
PropertyException.  Would this be a problem for anyone if it changed in this 
way?

Alex

------------------------------------------------------------

Changes to EvalDirective:-

    public void write(org.webmacro.FastWriter out, org.webmacro.Context 
context) throws org.webmacro.PropertyException, java.io.IOException
    {
        try
        {
// removed this as no longer necessary...
//             String s = null;
            Context c = null;

            Macro macro = (Macro)_evalTarget.getValue(context);
            if (_mapExpr == null)
            {
                // no map specified, use current context
// shift to write directly to master FastWriter:-
//               (String)macro.evaluate(context);
              macro.write(out, context);
            }
            else
            {
// <SNIP>
// shift to writ directly to master FastWriter
//                 s = (String)macro.evaluate(c);
                macro.write(out, c);
            }
// removed this as no longer necessary...
//             out.write(s);
        }
        catch (Exception e)
        {
            if (e instanceof PropertyException) throw (PropertyException)e;
            throw new PropertyException("#eval: Unable to evaluate macro.", 
e);
        }
    }