Debugging and Profiling XSLTs
In my day job I get to work on a lot of XSLTs consuming a variety of xml data formats and if you do as well, you will know how much of a trouble it is to debug arcane bugs in the transforms, and how much of a shot in the dark it is to write optimized transforms. The problem was exacerbated due to lack of simple debugging and profiling tools for XSLT. Worry no more.
I am extremely happy (and very satisfied) to note the release of Xslt Profiler addin for Visual Studio 2008 Team System (back in Feb 2008). Now this addin only works if you have VS Team System installed, since the add-in depends on the profiling tools that ship with that edition. For Visual Studio 2005 users here is a link to XML Tools in Visual Studio 2005 that you might find interesting.
I have been playing with this addin for a while now and I can already see its use as a nice debugging tool. I haven't played a lot with its profiling parts, and when I do I will log the process in a later post. Here is a video on channel9 that can quickly ramp you up on how to use this nice addin. Notice that in the video, the developer is actually profiling and debugging word2html.xsl which has shipped with Word 2003: XML viewer. The xsl is profiled, analyzed for top time consuming methods and optimized to perform better. It is definitely a nice way to showing how useful this tool is.
Some quick pointers from the video -
- Use XPathDocument instead of XMLDocument class; XPathDocument is much better optimized.
- Try to enable FastCaps to capture detailed XSLT execution information.
- Improving XML Performance.
Limitations of the addin -
- Needs VS 2008 Team System to work (dependency on profiling tools shipping with that edition).
- XSLTs that execute with parameters need workaround (load with hardcoded default.)
Now FastCaps wasn't very easy to search, so I have pasted the relevant information here, from this link -
If you would like to have more detailed results on Performance Reports, please add the following key to registry:
As you can see the reports will start to include all System.Xml runtime calls as well. The better analysis of System.Xml runtime will lead to better performing XSLT Instructions.