views:

1352

answers:

4

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

+2  A: 

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

lindelof
+8  A: 

Hi,

which XSLT engine are you using? If you are using the .NET engine and Visual Studio you could use the XSLT profiler available for VS 2008 which is a very useful (The Team System edition of VS is needed though). 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.

0xA3
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.
pauldoo
Post the problematic XSLT and I may help you find the problematic lines.
0xA3
As divo says: "Post the problematic XSLT and I may help you find the problematic lines" :)
Dimitre Novatchev
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.
pauldoo
XSLT profiler for Visual Studio is only available for the Team System SKU.
eddiegroves
There is a standalone profiler from Microsoft. It is called "XsltMajic Profiler Tool". There is a link for it in this KB: http://support.microsoft.com/kb/331026/
Ricardo Nolde
+1  A: 

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

null
+5  A: 

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