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.
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:
- 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
#PCDATAelement, 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