Saxon

Legacy ID: #7483312 Legacy Poster: Michael Kay (mhkay)

There are interfaces to save a compiled stylesheet to disk, but (a) they aren't available via s9api, and (b) they don't actually help performance significantly - loading the compiled stylesheet from disk turns out to take about as long as recompiling it from source in many cases. But by all means try it. The command-line Compile interface is a thin wrapper around internal calls to serialize the PreparedStylesheet object (in the sense of Java serialization) and if you want to do this from your own code, just copy-and-paste from net.sf.saxon.Compile.java. What I would recommend, though, is to reduce your problem of start-up time by compiling lazily, that is, compiling a stylesheet the first time it is used.

Legacy ID: #7486060 Legacy Poster: Lea Hayes (numberkruncher)

> (a) they aren't available via s9api I only used the s9api because is very closely resembled the code that I wrote using the .NET framework. Is the alternate approach generally preferred? If I understand correctly, there are two other approaches? > (b) they don't actually help performance significantly - loading the compiled stylesheet from disk turns out to take about as long as recompiling it from source in many cases. That's an interesting point. > if you want to do this from your own code, just copy-and-paste from net.sf.saxon.Compile.java I will take a look into that. > What I would recommend, though, is to reduce your problem of start-up time by compiling lazily, that is, compiling a stylesheet the first time it is used. I had actually already written that into the logic, and that has shown huge improvements in performance. I am keeping the processor and the compiled executable in a member variable. This did cause one problem with regards to "generate-id" and document numbering. After a while, generated identifiers were becoming extremely large where the number generator was not being reset. For now I have added the following line which appears to resolve this particular problem, but I fear that this could cause some internal damage: processor.getUnderlyingConfiguration().setDocumentNumberAllocator(new DocumentNumberAllocator()); I have tried using the reset() and clearDocumentPool() functions, but neither appeared to make any difference. I have, however, kept the call to clearDocumentPool() to ensure that XML documents are not cached because they can change in between transforms. Many thanks,

Legacy ID: #7487172 Legacy Poster: Michael Kay (mhkay)

>I only used the s9api because is very closely resembled the code that I wrote using the .NET framework. Is the alternate approach generally preferred? If I understand correctly, there are two other approaches? s9api tries to provide access to "mainstream" functionality, and to provide trapdoors to lower-level interfaces where appropriate. But occasionally there are things you can't do via s9api. I don't consider "compiling" (=serializing) to be mainstream enough, because user experience suggests that the benefits are often disappointing. >This did cause one problem with regards to "generate-id" and document numbering. After a while, generated identifiers were becoming extremely large where the number generator was not being reset. I can't quite see why large document numbers should be a problem. If you're running multiple threads sharing a Configuration, then it would only be safe to reset the DocumentNumberAllocator at a quiet point when nothing is happening, which in general is rather hard to determine. Rather than using reset() and clearDocumentPool() between transformations, I would recommend creating a new Transformer for each transformation. Cache the Templates object, which represents the compiled stylesheet, but create a new Transformer each time you use it.

Legacy ID: #7487678 Legacy Poster: Lea Hayes (numberkruncher)

> I can't quite see why large document numbers should be a problem. My concern was with when the maximum document number is met. My ASP.NET implementation is using multithreading, but the Java implementation, at the moment at least, is only using the one thread. > Rather than using reset() and clearDocumentPool() between transformations, I would recommend creating a new Transformer for each transformation. Thanks for that, I have now replaced those two calls with a new Transformer instance.

Legacy ID: #7487774 Legacy Poster: Michael Kay (mhkay)

>My concern was with when the maximum document number is met. At 100 transformations per second you'll overflow after 223 days - I suppose it's just about possible. I'll change it to a long.

Legacy ID: #7488163 Legacy Poster: Lea Hayes (numberkruncher)

Excellent, thanks again for your help!