[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Rule of thumb: Are XPath 2.0 or XSLT 2.0 constructs faster?


Subject: Re: [xsl] Rule of thumb: Are XPath 2.0 or XSLT 2.0 constructs faster?
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Thu, 09 Feb 2012 10:12:30 +0000

With performance questions, it always depends on the processor.

In Saxon 6, like most other XSLT 1.0 processors I have seen, the XSLT and XPath engines were very separate; the boundary between the two languages was very evident in the internal engine, both compile time and run-time. With this architecture, there might well be performance differences between equivalent XSLT and XPath constructs.

In Saxon 9, XSLT and XPath code compile to a single integrated expression tree, which is optimized and executed as a whole without concern for which parts originated as XSLT and which as XPath. So, for example, an XPath "if-then-else" will typically generate exactly the same code as an XSLT xsl:choose. The code generated by the xsl:for-each instruction is exactly the same as the code for the "/" operator in the case where the rhs has an atomic type. So you can safely make your coding decisions on what reads well, rather than what performs well. Of course, other XSLT 2.0 processors may differ.

If you want to improve both the readability and the performance of your code, as well as improving ease of debugging, the single best thing you can do is to declare the types of your variables and parameters as precisely as possible.

Michael Kay
Saxonica


On 09/02/2012 07:59, TW wrote:
Hi all,

in XSLT 2.0, I quite often find that I can do things using either
XPath or XSLT constructs.  For example, in a step-by-step calculation
I define a number of variables, either with<xsl:variable>  or XPath
"for $x in y" expressions.  I can use<xsl:choose>  or XPath's
if/then/else (single or chained).  Sometimes a goal can be achieved
with either<xsl:for-each>/<xsl:sort>  and more complex sort criteria
and return values, or max()/min() and some conditional treatment.

I like pure XPath solutions because they are less verbose, but I find
"full" XSLT less restricting and easier to debug (especially when I
want to check what variable holds what value).  But how does it look
performance-wise?  Is there a valid rule of thumb what constructs are
cheaper in general?  Do XSLT constructs maybe have an overhead that
XPath ones don't?

Thomas W.


Current Thread
Keywords