Re: [xslt] libxslt processor dump/load

[Daniel Veillard <veillard redhat com>]

On Thu, May 03, 2007 at 09:10:25PM +0200, Christian Stocker wrote:
> 
> 
> 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

  Having to fork the request to an external server should not have
to happen:
    - you do 2 full context switch 
    - you do data exchange between the processes
    - you force some kind of arbitrary serialization 
while natively libxslt should not need this. It seems the main
problem is that Apache was designed as an HTTP server i.e. an
engine with little state, where having forked servers is not
a problem, but when used with PHP this is not the case anymore.

  I understand the history but it seems we end up with a rather
baroque architecture as a result, and I wonder if some of the
problems raised by russian coders here a couple of years ago
about using distinct memory pools in libxml2/libxslt wasn't also
about trying to get rid of this problem.

  This looks like an interesting hack, certainly more efficient
but the real solution would be to run fully threaded in a single
process IMHO.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/