Re: [xml] Deep-copy of xsltStylesheetPtr?

[Daniel Veillard <veillard redhat com>]

On Sat, Sep 18, 2004 at 02:13:36PM -0700, Rasmus Lerdorf wrote:
> Well, after benchmarking, it turns out that xmlCopyDoc() is actually the
> bottleneck in this scheme.  It is way slower to call xmlCopyDoc() to copy
> the xmlDoc from shared memory to request memory than it is to simply
> reparse the XML document from disk.

   haha :-)
Err, well I certainly spent some time tuning libxml2 parser and tree
build, but never really spent time trying to optimize the copy operations.
I think they are far less common. Plus as I said they don't use the
dictionnary so the copied tree is certainly bigger. I think it would
make sense to optimize whole document copy though it's very different
from just taking bits of document A and trying to paste them in document B.

[... interesting bench snipped ...]
> This runs at around 267 requests/second which is close to the 274 that the
> XSLT processor did so PHP and libxslt seem to parse and substitute at
> about the same rate.  Now, if I read the xmlDoc dom struct out of shared
> memory in the above example I drop to 157 req/sec.
>
> The only way to get significant speedup is to cache the final $menu array
> that my simple little parser there creates.  If I grab $menu from shared
> memory then I jump to 600 req/sec.  A significant speedup.

  so it seems generating the result takes roughtly half of the time
spent on the server (I assume you have really fast RTT between client-server)
and also that loading the transformations and xml data is also roughtly
half of the processing time). The fact that the XSLT transfor is approximately
as fast as the direct manual transformation at the PHP level sounds good
that mean once compiled the interpretor of the stylesheet is on par with the
PHP interpretor (okay PHP need also to go back and forth between the 
managed env and the C level, lot of marshalling probably takes place).

> The conclusion to all this being that xmlCopyDoc() is just too damn slow
> for me to do it this way.  I either have to work directly from shared
> memory or cache beyond the xmlDoc stage like I did here.

  Well sure, caching the result is always best :-) , it's unclear from
your test how much the stylesheet load/compilation is, trying to use 
a read-only stylesheet from the cache at least as an experiment would be
interesting too.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/