How do I profile and optimize an XSLT?

Question

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 modest size (~1 MiB), and other XSLTs for the same document that do different processing execute much more quickly. So I know it isn't the size of the XML that is the problem, it's my XSLT.

How do I go about profiling and optimizing my XSLT?

(Is it a bad idea to be doing complex XSLTs in the browser? Should I instead apply the XSLT application side?)

Answer 1

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 :)

Answer 2

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:

1. Keep the source documents small. If necessary split the document first.
2. Keep the XSLT processor (and Java VM) loaded in memory between runs
3. If you use the same stylesheet repeatedly, compile it first.
4. If you use the same source document repeatedly, keep it in memory.
5. If you perform the same transformation repeatedly, don't. Store the result instead.
6. Keep the output document small. For example, if you're generating HTML, use CSS.
7. Never validate the same source document more than once.
8. Split complex transformations into several stages.

Eight tips for how to write efficient XSLT:

1. Avoid repeated use of "//item".
2. Don't evaluate the same node-set more than once; save it in a variable.
3. Avoid <xsl:number> if you can. For example, by using position().
4. Use <xsl:key>, for example to solve grouping problems.
5. Avoid complex patterns in template rules. Instead, use <xsl:choose> within the rule.
6. Be careful when using the preceding[-sibling] or following[-sibling] axes. This often indicates an algorithm with n-squared performance.
7. 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.
8. To output the text value of a simple #PCDATA element, use <xsl:value-of> in preference to <xsl:apply-templates>.

Answer 3

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:

1. Avoid repeated use of "//item".
2. Don't evaluate the same node-set more than once; save it in a variable.
3. Avoid <xsl:number> if you can. For example, by using position().
4. Use <xsl:key>, for example to solve grouping problems.
5. Avoid complex patterns in template rules. Instead, use within the rule.
6. Be careful when using the preceding[-sibling] or following[-sibling] axes. This often indicates an algorithm with n-squared performance.
7. 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.
8. 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.

Answer 4

The commercial Oxygen XML editor has a feature for profiling and debugging XSLT files. It's a good XML editor, too.