cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [IMP] Performance problems with TraxTransformer
Date Fri, 31 Oct 2003 20:08:22 GMT
Sylvain Wallez wrote:

> Vadim Gritsenko wrote:
>> Sylvain Wallez wrote:
> <snip/>
>>> XSLTProcessor
>>> -------------
>>> This component's design is intrinsically bad from a cache 
>>> perspective: the only way to access validity is through 
>>> getTransformerHandlerAndValidity which always creates the 
>>> TransformerHandler even if we don't use it. Combine this with 
>>> use-store=false, and we end up reparsing the XSL at each call.
>> The only way to obtain validity is to get it from the store. If store 
>> is not present, the alternative is to *compute* validity, which 
>> involves XSLT parsing and results in templates object. It will be 
>> silly to compute validity and loose templates, that's why method 
>> returns both at once.
>> If store is used, then templates are obtainer from the store for 
>> free, i.e. no CPU cycles used.
> Not exactly: the method returns a TransformerHandler, and not a 
> Templates (which serves as a factory to build TransformerHandlers). 
> And creating a TransformerHandler is a costly operation that is 
> useless when the pipeline is not executed and the result retrieved 
> from the cache.
> So a speed optimisation could consist in having 
> TransformerHandlerAndValidity create the handler lazily only when 
> requested, which would not occur if the pipeline is not executed.
> For this, we need TransformerHandlerAndValidity to hold the Templates 
> object.
> What do you think?

If creation of handler is costly -- then yes, it makes sense.

I feel like we are discussing it not the first time. Last time I was 
thinking about creation of pool of handlers per templates object, but 
this might be just too much :)


View raw message