cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [HEADS-UP] writing components for cache efficiency
Date Tue, 13 May 2003 17:17:50 GMT
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
> ...
>> So far so good. Now looking at TraxTransformer.setup(), we can see 
>> that it gets the validity _and_ and a TransformerHandler at the same 
>> time. And if the validity is still valid, the TransformerHandler is 
>> simply not used since the content is retrieved from the cache. So I 
>> hacked a bit to separate these, and obtained again a speed increase 
>> ranging from 5% to 30%.
> Here is the trick: to create validity, you have to load up XSLT and 
> create Templates. If you have validity in the cache, you have 
> Templates too (== no extra load on CPU).
> The only object which is re-created needlessly, every time, is 
> TransformerHandler (, line 612), and when you 
> are configured your Cocoon to use Xalan, this operation (IIRC) is not 
> exactly cheap. Possible solution I've seen is to pool those handlers 
> on per-template base.
> Another possible solution is to return Templates from the xslt 
> processor instead of TransformerHandler and have additional method 
> "templates2handler" to create TransformerHandler later in the game, 
> right before we start processing. 

The hack I used to workaround this is to separate getValidity from 
getTemplatesHandler. I say it's a hack, because flushing invalid 
Templates out of the cache is a side effect of checking the validity, 
meaning that if TraxTransformer is used in a NonCachingPipeline, 
stylesheets will not be reloaded.

Mmmh... maybe the simple solution is for TraxTransformer to check the 
template validity in setXMLConsumer _if_ getValidity() wasn't called.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message