Performance of custom XSL/XML Web Parts in SharePoint 2007

Developing custom Web Parts which leverage the concept of separating the presentation layer from the control provides you and your customer with great flexibility. Web Parts which produce XML output and render it using an XSL stylesheet given by the end user can be easily reused in multiple projects saving you in some cases some time. While working on the Extended Content Query Web Part I took a look at the performance of the XSL transforms and I have found out that there are thing to be considered while using that concept.

One of the probably greatest examples of using XSL transformation for the Web Part presentation layer is the Content Query Web Part. As it refers to external stylesheets, it is focused on reusability of these XSL transformations in multiple instances of the CQWP. To fully benefit of that concept you would create your custom XSL stylesheet containing the chrome of your web site and then create a sub classed CQWP referring to your stylesheet to provide consistent presentation layer across the whole web site.

In some cases however you might need to create your own web parts. Personally I find it a great approach to separate the presentation layer from the web part logic. It makes it possible for me to reuse the web parts I created once in multiple projects and focus on the challenges instead routine/repeating work.

The concept of XSL transforms is pretty easy. You provide an XML document containing your data, you define an XSL stylesheet which describes how you want your output to look like, and then you use the transform method provided by the .NET framework. Because that concept is so abstract it might by helpful to separate it from the custom web parts you create and create for example an abstract class providing the required Web Part Properties (like: Display XML (to show the raw XML output) and XSL). Developed once it will allow you to focus on the functionality to be built instead of copy & pasting the same code over and over again.

The .NET framework has introduced a new class for transforming XML using XSL called XslCompiledTransform. According to Microsoft it should work at least a couple of times faster than its deprecated version XslTransform. But is it really so? Does the XslCompiledTransform class perform better when used in web parts?

As the name says, the XslCompiledTransform class uses the compilation process to optimize the XML transformation. It compiles the XSL to the intermediate language to improve the overall performance. In many cases this XSL is static and stored within the application. By implementing the concept correctly you can gain some performance. But our web parts must allow users to provide their own XSL and thus is the XSL dynamic. Therefore it cannot be precompiled. To find out the actual cost of using the XslCompiledTransform I have used the Pager Web Part which I have created for paging Content Query Web Part results. The Pager produces XML containing available pages and the presentation layer is being determined by the provided XSL stylesheet:

<?xml version="1.0" encoding="utf-16"?>
<Pages>
    <QueryString><![CDATA[]]></QueryString>
    <Page Number="1" Current="true" />
    <Page Number="2" Next="true" />
    <Page Number="3" />
    <Page Number="4" />
    <Page Number="5" />
    <Page Number="6" />
    <Page Number="7" />
    <Page Number="8" />
    <Page Number="9" />
    <Page Number="10" />
</Pages>

Here are the results:

Using the XslCompiledTransform introduced in .NET 2.0 is in average about 15 times slower than using the depracated XslTransform. It seems like you can benefit of the power of the XslCompiledTransform only while running multiple transformation using the same XSL. The first transformation does all the heavy work but each following benefit of the compiled data.

Another thing that comes clear is that not using the pager at all causes another performance improvement: in average 10 times faster than the one using the XslTransform. Using a Pager Web Part with predefined chrome improves the overall performance but takes the reusability away. So depending on your case you might choose for the one instead of another.

Summary

What becomes clear of this test is that the deprecated XslTransform class is more suitable than the advised XslCompiledTransform when used in custom web parts. Decreased performance is the price you need to pay for reusability and flexibility of your custom XML web parts.

Technorati Tags: SharePoint, SharePoint 2007, MOSS 2007, WCM