Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
INFO: Performance of XSLT Transformations in the .NET Framework
Article ID: 325689 - View products that this article applies to.
This article was previously published under Q325689
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.
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:
(http://support.microsoft.com/kb/318580/EN-US/ )PRB: XSL Transformations with XmlDataDocument May Perform More Slowly Than XPathDocument
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:
(http://support.microsoft.com/kb/325693/EN-US/ )PRB: Slow Performance When Transforming an ADO.NET DataSet with Non-Nested DataRelations
100 Percent CPU Utilization or Hang When You Use XmlDocument to Execute XSLT Transformations that Use preceding-siblingUsing 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.
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:
(http://support.microsoft.com/kb/324478/EN-US/ )Slow XSLT Performance with Managed Parser
316775To 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).
(http://support.microsoft.com/kb/316775/EN-US/ )PRB: Cannot Unload Assemblies That You Create and Load by Using Script in XSLT
Microsoft recommends that you use XSLT extension objects to implement custom XPath extension functions and avoid the side effects of this anomaly.
For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/313997/EN-US/ )INFO: Roadmap for Executing XSLT Transformations in .NET Applications
Article ID: 325689 - Last Review: January 23, 2004 - Revision: 3.3