decorators, are they still supported, they have a performance penalty

[Robert Yates <ro...@gmail.com>]

All,

I am working my way through performance tuning the roller code.  One
of the things we are planning on doing is ensuring that Roller
performs well without the page caches within it (we are trying to
reduce the amount of memory that it uses and instead want to leverage
a reverse proxy for caching pages).  Again, you are welcome to all
this code, once we clear legal (this will probably be after xmas at
this point).

This has uncovered a number of things that I'll probably send separate
e-mails about, however one thing that has turned up is decorators.  At
the moment, if a theme has a decorator (and some have for no good
reason) it causes the entire page to be written into memory twice
(once for the cache and once for the decorator, the decorator can be
subsequently garbage collected, but these are still large allocations
if we are rendering lots of entries).

I also noticed that the Template guide makes no mention of decorators,
so I was wondering if this is something that Roller still officially
supports.  It it isn't supported could we remove the code for
decorators from VelocityRenderer.  It's a simple change i.e. just run
the else block (see below) and it would eliminate the rather large
allocations made by the StringWriter.

Let me know what you think,

Thanks,

Rob

            if(velocityDecorator != null) {

                /**
                 * We only allow decorating once, so the process isn't
                 * fully recursive.  This is just to keep it simple.
                 */

                // render base template to a temporary StringWriter
                StringWriter sw = new StringWriter();
                velocityTemplate.merge(ctx, sw);

                // put rendered template into context
                ctx.put("decorator_body", sw.toString());

                log.debug("Applying decorator "+velocityDecorator.getName());

                // now render decorator to our output writer
                velocityDecorator.merge(ctx, out);

            } else {

                // no decorator, so just merge template to our output writer
                velocityTemplate.merge(ctx, out);
            }

Re: decorators, are they still supported, they have a performance penalty

[Allen Gilliland <al...@sun.com>]

Yes, decorators are still supported.

We have tried to downplay them for a while now, but unfortunately there 
is no way remove them because the upgrade path of old Roller users would 
be very nasty.

If you were planning on setting up a new installation then as you 
mention below it would be very easy to disable them and remove that 
performance penalty.

-- Allen


Robert Yates wrote:
> All,
> 
> I am working my way through performance tuning the roller code.  One
> of the things we are planning on doing is ensuring that Roller
> performs well without the page caches within it (we are trying to
> reduce the amount of memory that it uses and instead want to leverage
> a reverse proxy for caching pages).  Again, you are welcome to all
> this code, once we clear legal (this will probably be after xmas at
> this point).
> 
> This has uncovered a number of things that I'll probably send separate
> e-mails about, however one thing that has turned up is decorators.  At
> the moment, if a theme has a decorator (and some have for no good
> reason) it causes the entire page to be written into memory twice
> (once for the cache and once for the decorator, the decorator can be
> subsequently garbage collected, but these are still large allocations
> if we are rendering lots of entries).
> 
> I also noticed that the Template guide makes no mention of decorators,
> so I was wondering if this is something that Roller still officially
> supports.  It it isn't supported could we remove the code for
> decorators from VelocityRenderer.  It's a simple change i.e. just run
> the else block (see below) and it would eliminate the rather large
> allocations made by the StringWriter.
> 
> Let me know what you think,
> 
> Thanks,
> 
> Rob
> 
>            if(velocityDecorator != null) {
> 
>                /**
>                 * We only allow decorating once, so the process isn't
>                 * fully recursive.  This is just to keep it simple.
>                 */
> 
>                // render base template to a temporary StringWriter
>                StringWriter sw = new StringWriter();
>                velocityTemplate.merge(ctx, sw);
> 
>                // put rendered template into context
>                ctx.put("decorator_body", sw.toString());
> 
>                log.debug("Applying decorator 
> "+velocityDecorator.getName());
> 
>                // now render decorator to our output writer
>                velocityDecorator.merge(ctx, out);
> 
>            } else {
> 
>                // no decorator, so just merge template to our output writer
>                velocityTemplate.merge(ctx, out);
>            }