Saxon

Legacy ID: #3403970 Legacy Poster: daiei27 (daiei27)

I just came across an article you wrote on how Saxon 6.5 works (http://www-128.ibm.com/developerworks/xml/library/x-xslt2/). It says, "reading the tree back into memory takes longer than recompiling the original (largely because of its increased size)." If this is still true with 8.5, is there any benefit to compiling an XSL separately like I was trying to do? Or is it only useful if you compile and run it multiple times within the same Java process.

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

It's a while since I've made any measurements in this area, so I ran a couple of experiments and got fairly similar results: loading a fairly large compiled stylesheet from disk is taking about 300ms, compared with the original cost of compiling it of around 400ms. These figures come from repeated compilations driven from the Java API, not from the -t option - measurements from the command line are almost meaningless, because they are completely dominated by the warm-up time for the Java VM. I'm slightly surprised by the results, because Saxon is doing more and more work at compile time. It's possible that I need to take another look at bringing down the size of the compiled module, or even doing my own serialization format as I did with the PTree. It's probably gradually crept upwards. There has never been a big performance win from saving compiled stylesheets on disk. The run-time execution is exactly the same. The main original motivation for making stylesheets serializable was to allow them to be relocated in J2EE application server environments that do load-balancing. I also know of people who are using them as a convenient way of distributing obfuscated stylesheet code to protect their intellectual property. Michael Kay

Legacy ID: #3406513 Legacy Poster: daiei27 (daiei27)

Well, that's a bummer. I was hoping we could shave some time off of XSL execution. I appreciate you looking into it. We're already looking into Java servlet options that keep the Java VM open, like Resin and Tomcat. If it's possible, could we compile Saxon itself so we wouldn't have to wait for the JVM to start up every time? Do you have any other ideas on cutting exec. times besides optimizing XSL (which I normally try to do)?

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

If you're running lots of small transformations then it's certainly important to use some kind of server environment that eliminates JVM startup cost (and that holds compiled stylesheets in memory). I don't know whether there are Java compilers that also help, its not an area I have explored much. Performance tuning is an area where Saxonica can offer consultancy help: contact me off-list if interested. Michael Kay

Legacy ID: #3409955 Legacy Poster: daiei27 (daiei27)

FYI. The only free native compiler I could find was GCJ (GNU Compiler for Java), which is included in GCC 3+. Unfortunately I was using GCC 3.4.3 and it appears that it only supports Java1.2 where Saxon requires Java1.4. I'm guessing that's why I get the javax.xml.transform errors when I try to compile anyways. There is a newer version, GCC 4.0.2, that includes javax.xml and other JAXP stuff so it may actually be able to compile saxon. I was told it doesn't include some of the DOM API, but I believe your article said you avoid it for performance reasons. I'm having trouble building it at the moment, but I'll try to remember to update this thread if I figure it out.

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

Saxon isn't actually that heavily dependent on the XML parsing interfaces that came in with JDK 1.3, since they're all available as free-standing components. What Saxon does need in JDK 1.4, however, is the regular expression support (and the CharSequence interface). It also uses the java.net.URI class extensively. Michael Kay