Jacek R. Ambroziak
7/02/2001
Gregor, the new XSLT Compiler for Java, will be moving to Beta Testing with customers within about 2 weeks. The XSLT 1.0 functionality is almost complete. id/key indexing is not yet supported but integration with arbitrary Java methods, both static and instance, as well as XSLT 1.1-style Temporary Trees are supported.
Gregor's goals have been reliability and performance, both intended to be reached by different paths than has been the case with my previous work: Sun's XSLTC, now a part of Xalan@Apache. Gregor aspires to match the functionality of Saxon while surpassing the performance of XSLTC. To assess the speed of Gregor transformations the popular XSLTMark benchmark has been used.
When analyzing the early performance results it is important to remember that Gregor is only very recently put together and it does not yet perform optimizations that its new architecture enables. Competing against XSLTC is not easy either: the older solution is already very fast. And yet Gregor's early results are encouraging. All tests have been conducted on a Dell Inspiron 8000 notebook powered by a 900MHz Pentium III, with 256MB of RAM, running Red Hat Linux 7.1 with the 2.4.18 kernel.
Four XSLT solutions have been compared: Saxon 6.5.1, Apache Xalan 2.4D1, Sun/Apache XSLTC (2.4D1) and Ambrosoft's Gregor 0.9.
The processors ran on 4 different Java VMs: Sun's 1.4.0 and (the newest) 1.4.0_01, IBM's Java2/1.3, and BEA's JRockIt. The tests have been run on a 'pure' Linux console with no X-server or any other applications running.
XSLTMark's harness runs a suite of tests, each consisting of:
1. input XML data
2. an XSLT transformation to be applied to the data
3. number of times the transformation is to be performed (iterations)
The test harness times each example individually and at the end produces a summary report with a single Aggregate Results number representing the performance of a processor against the suite. The bigger the number, the better. Here are the results and analysis.