INFO: Performance of XSLT Transformations in the .NET Framework (325689)

SUMMARY

This article contains information about the causes of and solutions or workarounds for known performance problems that you might experience when you use the .NET Framework XSLT processor to execute XSLT transformations.

back to the top

XSLT Transformations with XmlDataDocument Perform Slowly

Applying an XSLT transformation to the XML representation of the data in an ADO.NET DataSet is a common application requirement. The Microsoft .NET Framework base classes in the System.Xml namespaces are used in conjunction with the ADO.NET DataSet to implement this requirement in .NET applications.

System.Xml.Xsl.XslTransform is the base .NET Framework class that is used to execute XSLT transformations. System.Xml.XmlDataDocument, System.Xml.XmlDocument, and System.Xml.XPath.XPathDocument are the three base .NET Framework classes that can be used to load and supply the XML representation of the data in an ADO.NET DataSet as the source XML when an XSLT transformation is executed. Of these three options, using an XmlDataDocument object requires the least code because it can be synchronized directly with a DataSet object when it is instantiated. However, slow performance is a common problem when you use an XmlDataDocument object to apply an XSLT transformation to the XML representation of an ADO.NET DataSet. This behavior is by design in the RTM release of the .NET Framework.

System.Xml.XPath.XPathDocument is the most optimized class for XPath and XSLT processing. Load the XML representation of the DataSet data in an XPathDocument object and supply the XPathDocument object as the source XML when you execute an XSLT transformation to get maximum performance. For additional information about this problem and for a code sample that demonstrates how to implement the described workaround, click the article number below to view the article in the Microsoft Knowledge Base: back to the top

Slow Performance When Transforming a DataSet with Non-Nested DataRelation Objects

Slow performance is a common problem when you try to transform the XML representation of a DataSet that has multiple related DataTable objects and whose DataRelation objects have not been nested to reflect a hierarchical structure to depict the relationships in the serialized XML.

When you try to transform such XML data to a different hierarchical format (such as an HTML table that displays the data in a parent-child hierarchy), you must use XPath location path axes such as following-sibling and preceding-sibling that can slow down the transformation process when you have medium to large volumes of data.

In such situations, Microsoft recommends that you nest the DataRelation objects of the DataSet (that is, set the Nested property of the DataRelation to True) and write code in the XSLT style sheet that uses natural top down hierarchical XPath query expressions to locate and transform the data. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: back to the top

100 Percent CPU Utilization or Hang When You Use XmlDocument to Execute XSLT Transformations that Use preceding-sibling

Using an XmlDocument object to supply the source XML to an XSLT transformation that uses the preceding-sibling XPath location axes causes 100 percent CPU utilization, which causes the computer to stop responding (hang) and also causes a steep drop in the system performance.

This behavior is noticeable when you transform medium to large XML documents or streams. This is currently a known problem in the RTM release of the .NET Framework. Microsoft is working to prevent the 100 percent CPU utilization in the next major release of the .NET Framework. Enhancing XmlDocument to match the performance of XPathDocument when you execute XPath queries and XSLT transformations is not a design goal for future releases of the .NET Framework.

The XPathDocument class is the recommended interface in .NET to load XML when an application must execute XPath queries or XSLT transformations on the XML data. If you experience this problem, modify your code to use an XPathDocument object to supply the source XML to the XSLT transformation process.

back to the top

Slow Performance When You Use xsl:key

The xsl:key XSLT element is frequently used to group XML data or identify unique occurrences of specified element or attribute values in the source XML. XSLT style sheets that use the xsl:key element exhibit slow performance when they are used to transform XML data in .NET applications. This is caused by a known problem in the XSLT processor implementation of the xsl:key element in the RTM release of the .NET Framework.

A fix to address this problem is currently available. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: back to the top

Managed Assemblies Generated for Inline Script Blocks Are Not Released Correctly

In the .NET Framework, managed assemblies are generated and loaded implicitly to execute the code that is contained in inline <msxsl:script> blocks. A known problem in the RTM release of the .NET Framework prevents these assemblies from being correctly unloaded when the transformation process is complete. This anomaly can cause an incremental increase in memory usage, resulting in a drop in system performance, if the affected style sheet is repeatedly loaded to execute XSLT transformations. The unreleased memory is released only when the host process is recycled. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: To work around this anomaly in ASP.NET applications, load the affected style sheets only one time during the life of the application, cache the style sheets in the ASP.NET cache, and reuse the cached versions for later transformations. In Windows Forms and Console Application projects, you can use global XslTransform object instances to load the affected style sheets at application startup and execute later transformations. These workaround methods are not applicable when the XSLT transformation must be executed in a stateless environment (for example, middle-tier Enterprise Services components).

Microsoft recommends that you use XSLT extension objects to implement custom XPath extension functions and avoid the side effects of this anomaly.

back to the top