RE: [xsl] Optimization Question

Subject: RE: [xsl] Optimization Question
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Tue, 1 Feb 2005 09:31:06 -0000
>     Have you tried XSLTC. This basically allows you to apply 
> a compiled
> form of your stylesheet in your transformations. Both xalan 
> and saxon ship with XSLT compilers. 

There's a lot of misunderstanding in this area, because the boundary between
compilers and interpreters is a pretty fuzzy one.

Part of the confusion is that XSLTC actually ships as part of the Xalan
package. I'm not sure what to call the "traditional Xalan", let's call it

XSLTC's analysis phase generates Java bytecode, which is then interpreted
(or just-in-time-compiled) by the Java VM. The generated bytecode, of
course, contains many calls on a run-time library. Saxon and Xalan-J, by
contrast, generate an in-memory data structure (the equivalent of a query
execution plan in relational systems) which is then interpreted by the
run-time code.

All these processors are doing as much of the work as they can at
compile-time, which gives benefits if you use the same stylesheet to
transform many source documents. The biggest benefit of XSLTC's approach
seems to be not so much speed (though it's fast) but the size of the
generated code, which makes it much more viable to download for execution on
the client - Saxon and Xalan-J are rather large JARs for this.

Whether you generate bytecode or not, many of the operations that take time
- XML parsing and tree building, copying, sorting, serializing, are likely
to be done by routines in the run-time library; they aren't affected by
compilation at all.

I'm asked occasionally whether I plan to do a Saxon compiler - more
strictly, a bytecode generator. At present, I don't: I think it would slow
down the rate of progress on the product considerably, if only because code
generators are notoriously hard to debug. I prefer to spend the effort on
improving the query execution strategies, which can produce much bigger
potential savings. In any case, I think that for most people memory is more
of a constraint than processing speed.

Michael Kay

Current Thread