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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--