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

Exemplification

IF you provide the XSLT code and the XML document on which you observe the problem, I and other people could try to help. – Naphthalene

Note: XSLT profiling and (better) debugging have been added to Visual Studio 2010. Of course, this is still XSLT 1.0. – Ocam

Answer 1

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.

Nomography

I am running in the browser, so my XSLT engine is whatever Firefox, IE, and Safari use. I understand that each engine will behave differently with the same XSLT, so profiling one particular engine may not reflect all 3. – Exemplification

Post the problematic XSLT and I may help you find the problematic lines. – Nomography

As divo says: "Post the problematic XSLT and I may help you find the problematic lines" :) – Naphthalene

I've employed xsl:key and that has made a massive difference. It's now 10x faster on small samples, and there is an even larger difference on big samples. I'll get the rest of my features implemented before I try some of the other optimizations. – Exemplification

XSLT profiler for Visual Studio is only available for the Team System SKU. – Strickle

There is a standalone profiler from Microsoft. It is called "XsltMajic Profiler Tool". There is a link for it in this KB: support.microsoft.com/kb/331026 – Calculate

The Visual Studio link seems to have moved to microsoft.com/en-us/download/details.aspx?id=10986 – Populous

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>.

Naphthalene

Answer 3

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

Mystify

Answer 4

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

Berserker

Answer 5

I would add "Use key for joins/lookups", as best practise.

I just lowered the time for a lookup from 400 sek to 13 sek with the use of "key" of y with id as key, instead of /x//y[id=$id].

Otolith