Based on a request we got from Upayavira, Vadim ran benchmarks on the XT XSLT processor using the same test suite we used for GT2005, and was favorably impressed. XT performed as well as XSLTC, while using a bit more memory, but still less than all the other contenders benchmarked to date. We will include XT results in our final writeup of the benchmarks (not yet completed, still working on Gregor testing.)
Vadim made a comment that XT might become his new favorite XSLT processor, which surprised me because (a) Vadim is a big proponent of All Things Apache and (b) XT does consume more memory than XSLTC. I asked him about this, and here’s how he responded (direct from an e-mail):
Major one is overall system complexity. The less count of moving parts, the better. XSLTC:
- Requires byte code engineering: BCEL library dependency.
- Requires templates to be less than 64Kb: Not sure if it is fixed in XSLTC, but possible to fix.
- Slow re-loading: Bytecode generation & loading is slower than parsing into Templates object.
- Side effects: Generated classes will utilize some non-heap memory.
- ClassLoaders had to be re-loaded in order to re-load XSLT. Sometimes it is PITA to reload a ClassLoader …
- Side effects: Re-loading of XSLT causes HotSpot to start from scratch.
- Size: Xalan+BCEL = 3.2Mb; XT = 0.5Mb
XSLTC is not bad, actually, but if its performance improvements are only marginal (as shown), then I prefer XT.
I’m not completely sold yet; XT is currently a one-person project, not much is happening on new development, and we haven’t yet given it a heavy workout on a large set of XSLTs to see what breaks. Regardless, quite interesting …
