---- you [EMAIL PROTECTED] (Kevin A. Burton - burtonator) wrote ---- > Is there any Xalan performance benchmark documentation?
Sorry, the docs here are definitely lagging. We do have a set of auotmated performance tests: cd xml-xalan/test build perf Note that while IMO we have a much richer set of Java test code to measure performance than any of the other oft quoted benchmarks, we do not have a very good selection of stylesheets checked in - only a couple. One interesting experiement (I've checked it in but haven't tested it thouroughly yet) is to try getting the XSLTMark set of stylesheets and then run our Java test code against them with something like: build perf -Dperf.fileList=xsltmark/testcases/default.conf although you have to ensure the pathing information in the default.conf listing of the xsltmark tests to run is correct, since our Java test code needs the correct path (or to be in the current directory). > Specifically I am looking for Xalan performance in certain situations. > - JDK 1.1, 1,2 1,3, 1.4 Be careful and ensure when testing in 1.3 and especially 1.4 that you're using all the classes you expect (i.e. you are provably using the Xalan version you want, and not the one bundled in the JDK or extensions) > - Using different sources and outputs. IE StreamSource going to StreamResult > and then all the combinations therein. Yup. The idea is for testing in general (and performance testing as well as other conf/etc testing): StylesheetTestletDriver : manages finding the set of stylesheet tests you want to run (either via discovery in a directory tree or via -fileList) StylesheetTestlet (and subclasses: PerfTestlet, etc.) defines the testing algorithim: in this case, basically: testletInit - simple setup testDatalet - call a Wrapper to transform an XML doc with that stylesheet, checkDatalet - validate the output on disk from testDatalet, if applicable handleException - handle exceptions from the above calls TransformWrapper (and subclasses: TraxStreamWrapper, TraxSAXWrapper, etc.) - encapsulate the transformer: main call is: long[] transform(String xmlName, String xslName, String resultName) The Wrapper's job is to get the xmlName doc transformed with the xslName into the resultName file on disk, using whatever API's are appropriate to get the transformer to do the job. With TrAX/JAXP transformers, I've done the semi-'canonical' ways to use SAX, DOMs, Streams, and systemId's to get transforms done, which is a good start. We should add a TraxPipeWrapper at some point as well. As a side effect, wrappers return an array of timing data for various stages of the whole operation, like XSLPARSE, XMLPARSE, TRANSFORM, etc. Depending on the kind of wrapper, this will give you much more detailed performance characteristics than the XSLTMark stuff will: i.e. for Streams, the Wrapper explicitly separates reading from disk from parsing the content from performing the transform. Of course for SystemIds, we don't separate this out because it's not simple to get from the JAXP API's OK, someone break in here and let me know 1) if anyone's still reading, and 2) if any of this makes sense. > - Using Xalan in pipe situations. Haven't really covered this yet, but it's obviously becoming much more popular. - Shane
