OK. The terminology is confusing (and it's going to get worse when Java code generation hits the streets). I'm not sure now what you meant when you asked about a "precompiled stylesheet".
 
If you do the normal JAXP thing of creating a TransformerFactory, then doing newTemplates() to create a Templates object (which in Saxon is actually a PreparedStylesheet), and then do newTransformer() on this to create a Transformer (= Saxon Controller), then
 
* the TransformerFactory can be shared as widely as you like
 
* the TransformerFactory owns a Configuration which can be shared
 
* by default, all Configurations in the VM share the same NamePool; I'm changing the default in the next version so there will be one NamePool per Configuration
 
* the Templates object, once created, can be shared (you can create as many Transformers as you like and run them in different threads), but these threads must all run under the Configuration/NamePool that was used to create the Templates
 
If you serialize a Templates (PreparedStylesheet) object to disk, and then reload it, then it obviously can't run in the original Configuration or with the original NamePool. When it is deserialized, a new NamePool is created as a clone of the original; there's no way therefore to run two such stylesheets with the same NamePool, and as a result they can't share a Configuration either. So yes, deserialized stylesheets cannot be run in a multithreading Configuration, other than one that's dedicated to multiple instances of the same stylesheet.
 
It's also true, as you suggest, that doing a setNamePool() on the Configuration will cause havoc to existing things that are using that Configuration. What you can do, of course, is to make changes to the contents of the NamePool - that's done under semaphore and is safe. (At what stage it becomes a bottleneck is another question).
 
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 21:11
To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] Compiled ss w/ Saxon8

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


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
saxon-help mailing list