I am working for a project which has many XSLT transformations. The transformations have to be as fast as possible.
For readability I wrote many of them dividing "business logic" and "output". For example
<!-- Business Logic -->
<xsl:variable name="myLocalVar">
<xsl:value-of select="func:whateverComputation(params)" />
</xsl:variable>
<!-- more buss logic here -->
<!-- Output -->
<xsl:element name="mytag">
<xsl:value-of select="$myLocalVar" />
</xsl:element>
Of course this can be written in a compact form
<xsl:element name="mytag">
<xsl:value-of select="func:whateverComputation(params)" />
</xsl:element>
Is the first form slower than the second one?
XSLT is faster and more concise to develop than performing transformations in Java. You can change XSLT without having to recompile the entire application (just re-create EAR and redeploy).
XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL. But XSLT isn't widely used client-side, that is, in the browser.
Streaming Transformations for XML (STX) is an XML transformation language intended as a high-speed, low memory consumption alternative to XSLT version 1.0 and 2.0.
From a section of the the XSLT FAQ:
xsl:variables
are dynamic values. These variables are not in cache, and run every time that they are referenced in XSL. Explicit type casting of xsl:variable
improves the performance. You can do type casting with string()
and boolean()
functions.
For example:
<xsl:variable name="_attr" select="string( /node/child[ @attr ] )">
Instead of using sub-elements, use attributes wherever possible. Using attributes instead of elements improves the performance. When performing XPath matches, attributes are faster because they are loosely typed. This makes validation of the schema easier.
When you match against attribute values, use enumerator attributes. Use multiple attribute names as bits, and set their values to true or false.
Keep the source documents small. If necessary split the document first.
Keep the XSLT processor (and Java VM) loaded in memory between runs
If you use the same stylesheet repeatedly, compile it first.
If you use the same source document repeatedly, keep it in memory.
If you perform the same transformation repeatedly, don't. Store the result instead.
Keep the output document small. For example, if you're generating HTML, use CSS.
Never validate the same source document more than once.
Split complex transformations into several stages.
Avoid repeated use of "//item".
Don't evaluate the same node-set more than once; save it in a variable.
Avoid <xsl:number>
if you can. For example, by using position()
.
Use <xsl:key>
, for example to solve grouping problems.
Avoid complex patterns in template rules. Instead, use <xsl:choose>
within the rule.
Be careful when using the preceding[-sibling]
or following[-sibling]
axes. This often indicates an algorithm with n-squared performance.
Don't sort the same node-set more than once. If necessary, save it as a result tree fragment and access it using the node-set()
extension function.
To output the text value of a simple #PCDATA
element, use <xsl:value-of>
in preference to <xsl:apply-templates>
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With