Okay, well maybe I misspoke slightly - according to the docs for the PreparedStylesheet object at http://www.saxonica.com/documentation/javadoc/index.html, where it describes the parameters to loadCompiledStylesheet():

    config - The Configuration. This method changes the NamePool used by this configuration to be the NamePool that was stored with the compiled stylesheet. The method must therefore not be used in a multi-threaded environment where the Configuration (and NamePool) are shared between multiple concurrent transformations.

I inferred that any method that modified the NamePool in the Configuration would render the Configuration non-shareable, so it was best to just treat the Configuration object itself as non-shareable in this situation.


Chris


On Feb 7, 2007, at 12:56 PM, Michael Kay wrote:

A Configuration does allow multithreaded access, most definitely!
 
I'm wondering how I misled you on that, it sounds as if there's some documentation that needs fixing.
 
Michael Kay
http://www.saxonica.com/


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Chris von See
Sent: 07 February 2007 20:33
To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] Compiled ss w/ Saxon8

Hi Michael -

In a similar vein... have you by any chance worked out a way to share a precompiled stylesheet and its associated Configuration object across multiple threads? We have a web-based app that uses a precompiled stylesheet, but we find that because the Configuration object does not allow multi-threaded access (according to the Javadoc) we cannot share the PreparedStylesheet object across servlet threads...

Thanks
Chris



On Feb 7, 2007, at 11:39 AM, Michael Kay wrote:

I'm afraid this isn't a surprise. It's a while since I looked at this area: I did manage to get the loading of compiled stylesheets down to about half the original compilation time by looking very carefully at the output of the object serialization, but it's almost certainly degraded since as a result of extra functionality and optimization, which increases the size and complexity of the expression tree that's being serializer. The existing stylesheet compilation offers no performance benefits, and I'm retaining it only because there are a handful of users who find it a good way of distributing tamper-proof code. I'm working on generating Java code as a replacement for the feature.
I find the other part of your suggestion, that compiled stylesheet run slower, difficult to believe. It's probably an effect of Java warm-up time - which, incidentally is probably as much a challenge in your environment as stylesheet compilation time.
I think a better solution to your problem would be to set up some kind of server in which Saxon is running - perhaps a web service - that accepts requests from your Perl application, and that can retain resources (like the Java VM and the stylesheet cache) between requests.
Michael Kay


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of Derose, Steve (NIH/NLM/NCBI) [C]
Sent: 05 February 2007 22:41
To: saxon-help@lists.sourceforge.net
Subject: [saxon] Compiled ss w/ Saxon8

My colleague here has been trying out launching Saxon 8 with compiled stylesheets.
Our basic problem is that we need to run many documents through the same stylesheet, and would like to not reload it every time. Since we're controlling the process from Perl, as far as we can tell we have to launch Saxon for each document -- so we thought we could save some time by pre-compiling.
What he has found, though, is something like these times:
200 line xslt
2MB xml document
run from non-compiled ss: 5.2s
run from compiled ss: 6.2s
Should it be slower to read and use compiled stylesheets, than plain original text ones?
I understand there's overhead for deserializing; but is it really more than the cost to parse from scratch?
Or might there be something obvious we're missing? Any particular construct that might be very costly to reload?
He also noticed that the time difference didn't seem constant across xml document sizes: smaller documents would
have a smaller time difference, suggesting that compiled stylesheets actually *run* slower rather than just load slower.
Not knowing the guts of the implementation, I would have predicted that once loaded they'd run almost exactly the same
as if they hadn't been pre-compiled.
Thanks for any light you can shed.
S
Steve DeRose (contractor) deroses@mail.nih.gov
PubMedCentral, National Center for Biotechnology Information
National Library of Medicine, NIH
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
saxon-help mailing list

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help