Re: [xslt] libxslt processor dump/load

[Christian Stocker <chregu bitflux ch>]

On 2.5.2007 20:07 Uhr, Daniel Veillard wrote:
> On Thu, Apr 26, 2007 at 06:36:19PM +0930, Andrew Mason wrote:
>> Aside from reducing the  bulk of the XSLT, is there anything that can be done 
>> from an XSL stylesheet POV or from a libxslt POV to reduce the  overhead  of 
>> importing the stylesheet?

Interesting discussion and thanks for the thorough answer, Daniel. I've
been asked that question about "compiled" stylesheets all the time.

This whole post made me think again about a solution I always wanted to
try regarding importing the stylesheet with a dedictated PHP daemon. You
can read  about it and see a proof of concept (and some impressive
benchmarks) here:
http://blog.liip.ch/archive/2007/05/12/pimp-up-your-xslt-transformation.html

(I'm not trying to do blog-whoring here, but I don't want to repeat
myself either :) )

It may not be the solution Andrew was looking for, but for some
specialiced services it may be a way for improving transformation times.

chregu
> 
>   Do you *really* need a 174 KByte stylesheet. I hope you understand
> this is insanely large. The compiler cannot optimize based on what you're
> gonna give to it, so basically it will have to compiler everything even if
> 2% is actually used by the tags embedded in your document.
>   So really the #1 thing to do is reduce your stylesheet to match the
> actual processing need. And remember, XSLT is really not a good general 
> pupose programming language it is only good at XML tree transformation
> and trying to use it for other kind of processing is just well not the
> right tool.
> 
>> We've spent the last 2 weeks going over various solutions, axkit, mod_xslt, 
>> xstlc etc.. and I have posted to the xslt users list and none of them are 
>> really optimal for our needs / setup for various reasons.
> 
>   I think sharing the compiled stylesheet between all your apache processes
> would be the #2 approach to follow. I have only very old remains of Apache
> memory model, but in a thread based setup that should be doable.
> 
>> The best solution for us and indeed most small multi-site development 
>> companies, would be to be able dump/save/cache in some way (disk would be 
>> ideal), a complete xslt processor after it has loaded the stylesheet. On  a 
>> request, get libxsl to 'import' this  pre-built xslt processor, at which we 
>> can throw our xml to be transformed. 
> 
>   It's unlikely you would gain much, sorry. The compilation process is 
> actually relatively lightweight and the XML parser itself is extremely
> fast. An ad-hoc implementation of a parser for a data format that has 
> no standard and hence not much use would be certainly poor and likely
> not much faster.
> 
>> First of all is this at all possible and secondly is it even a good idea?
> 
>   I don't think it's a good idea, and the possibility sounds feasible 
> but an awful lot of work, really, go have a look at libxslt internal
> data structures, you would ahve to save the tree too since it's still used,
> yeah really it's unlikely to be faster.
> 
>> It's really not an overall performance thing, it's more about per request 
>> latency. We aren't in a position to trade memory for latency due to how PHP 
>> works, but we think with something like this, we could reach a more than 
>> acceptable latency.
> 
>   You really should keep the compiled stylesheet in memory as a single
> instance, libxslt in itself allows this, it can be use by parallel threads
> running a transformation with the same stylesheet.
>   The last possibility #3 would be to profile the compilation process
> based on xsltproc and some runtime profiler and try to find out if your
> XSLT code doesn't trigger some non-linear behaviour, but again this would
> take time, and learning your XSLT and trimming it down seriously still
> sounds the sanest approach.
> 
> Daniel
> 

-- 
christian stocker  |  Liip AG  |  schoeneggstrasse 5 |  ch-8004 zurich
phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.liip.ch/  |  christian stocker liip ch  |  GnuPG 0x5CE1DECB