I have an XSLT for viewing XML files in the browser. The XSLT is naively written and currently takes a long time to execute (several minutes).
My XML file is of mod
The commercial Oxygen XML editor has a feature for profiling and debugging XSLT files. It's a good XML editor, too.
If you provide the XSLT code and the XML document on which you observe the problem, I and other people could try to help.
Here are some XSLT usage and performance tips from Michael Kay:
Eight tips for how to use XSLT efficiently:
Eight tips for how to write efficient XSLT:
//item
".<xsl:number>
if you can. For example, by using position()
.<xsl:key>
, for example to solve grouping problems.<xsl:choose>
within the rule.preceding[-sibling]
or following[-sibling]
axes. This often
indicates an algorithm with n
-squared performance.node-set()
extension function.<xsl:value-of>
in preference
to <xsl:apply-templates>
.which XSLT engine are you using? If you are using the .NET engine and Visual Studio you could use the XSLT profiler integrated into Visual Studio which is a very useful.
Other excellent profiling tools are Altova's XML Spy and Oxygen.
If you would post your XSLT it would be easier to tell you where possible bottlenecks are. In general be careful with XPath expressions such as '//', preceding::* and following::*. Some more rules and best-practices:
- 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 within the rule.
- Be careful when using the
preceding[-sibling]
orfollowing[-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>
.(from http://www.dpawson.co.uk/xsl/sect4/N9883.html#d15756e150)
Following these rules will typically result in very efficient XSLT and you possibly won't need to use a profiler at all.
Concerning your question about XSLT in the browser: I wouldn't recommend it because first you are not platform independent (not every browser might support it or some browsers may only support it with a poorly performing engine) and second you can't control the engine used.
I like to use Altova's XMLSpy for Windows based machines. It also has a profiler built-in. You can check out a video on using the editor. (scan to 5:45 to learn more about the profiler). It is a commercial product... with a time-trial period :)