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 :)
Vadim
