Benchmark XSLT performance

Question

I am trying to benchmark two versions of an XSLT. Currently I use Visual Studio to debug since xml transformations which are invoked from a .NET component. VS 2010 is the IDE I use for development.

Only clue I get is from the output window (below is an e.g.):

Stylesheet load time: 656.2 ms
Stylesheet JIT time: 11.18 ms
Stylesheet execution time: 177.8 ms

I believe I just need to be bothered with "Stylesheet execution time" but not sure if these values do reflect the actual capability of the XSL since that seems to be continuously varying for every run.

I would like to know if there is a reliable way to benchmark XSL. Any hands-on experience share in benchmarking XSL with .NET runtime would be helpful.

Answer 1

To conclude I am summarizing this for a quick reference for someone who might refer to this thread in the future:

For .NET the easiest way to benchmark is to use XSLT profiler. But the catch is it's only available with Microsoft Visual Studio Team System with Profiling Tools installed.

Another good option available is XT-Speedo an open source tool from Saxonica. Try it.

Apart from this for a quick-and-dirty assessment you can run multiple transformation of your XSLs and use a simple StopWatch Tick to get an average which may be sufficient in most cases.

Answer 2

This question has been asked before in stackoverflow you can see the original question here: How do I profile and optimize an XSLT?

Below is a snippet from the accepted answer:

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][4])

Originally from : https://stackoverflow.com/users/40347/0xa3

I would make sure the XSLT you can calling is compiled before running that way you are not getting mixed metrics from the compilation process that happens every time.

You can use the XslCompiledTransform class to ensure the XSLT is compiled before running. Very important that you do not dispose of that and reuse the transform other wise every time you create the object again it will recompile and take a random time to do it.

There is an interesting article here: http://www.windowsdevcenter.com/pub/a/dotnet/2003/07/14/xsltperf.html called XSLT Performance in .NET

It goes on to benchmark XSLT transform in .Net to other xslt engines.

My experience working with XSLT is that has been very fast most unless custom function were added to the transform eg. calling custom code that was not performante usually small to medium sheets should run pretty fast specially of you dont have many imports and function calls.

If you are really worried there is a brilliant article from MSDN Enterprise Patterns and Practices with a section about performance on XML and XSLT transformation.

The article is here: http://msdn.microsoft.com/en-us/library/ff649152.aspx

The section I am talking about is here: http://msdn.microsoft.com/en-us/library/ff647804.aspx

Microsoft did a post on Benchmarking XSLT which is an interesting read. http://blogs.msdn.com/b/antosha/archive/2006/07/24/xslcompiledtransform-performance-beating-msxml-4-0.aspx

There also a way to pre-compile style sheet into code so the xslt transforms are only loaded and not parsed at all.

You can find information about this here: (Using Precompiled XSLT in .NET) http://my-tech-talk.blogspot.co.uk/2009/03/using-precompiled-xslt-in-net.html

Answer 3

You might like to look at the paper we (Michael Kay and Debbie Lockett) published recently at XML London, see

http://xmllondon.com/2014/xmllondon-2014-proceedings.pdf

which describes some of the pitfalls that arise when benchmarking XSLT performance. See also the project on Github

https://github.com/Saxonica/XT-Speedo

To get repeatable results it's essential to run a transformation repeatedly and take an average.