Question

Which is faster, XML with XSLT or CLR with DataBinding?
I’m assuming that it’s CLR + Databinding but I could be wrong.

Answer 1

This is actually a question very close to my own heart, as almost all the work I do revolves around XSLT design layers with a custom .NET based backend that generates data (I love the system to death).

To the best of my knowledge, there are a few things that should be kept in mind:

• Make absolutely sure you use cached instances of System.Xml.Xsl.XslCompiledTransform. This class uses System.Reflection.Emit to create on demand classes that will absolutely PUMP OUT your xslt transformation incredibly fast

  • Use the right data structure as the input into your xslt transformations. If you have an XmlDocument (or better yet an XPathDocument) available, use that. Otherwise, for very large input documents and transformations pass in an xml reader (if available), since XslCompiledTransform will load the document into a XPathDocument (which are optimized for XPath access). Just to add, there exists an extension method in System.Xml.XPath for the System.Xml.Linq.XElement type that will create an XPathNavigator from a XElement, which will come in handy if your source data structure is an XElement

  • Do not use msxsl:script tags in your xsl transformations. msxsl:script tags are compiled differently than the rest of the xslt and can cause serious memory leaks in high-demand applications (they load custom assemblies EVERY TIME the xslt is run)

  • Avoid the use of extension methods as much as possible. I disassembled (reflector FTW) right down to the .NET source for executing extension methods in XSLT transformations and at the very heart it really is nothing more than a call to MethodInfo.Invoke(). A few calls won’t ruin your application, but don’t think you can make up for all of XSLT’s shortcomings using extension methods (might change in a future version of the framework, since they are caching extension methods in a custom hashing system, it is very possible that they could translate this to use compiled linq expressions, in which case it would be lightning fast)

  • To the best of my knowledge, System.Web.UI.DataBinder still boils down to a call in System.ComponentModel.ReflectPropertyDescriptor that uses System.Reflection.MethodInfo.Invoke() in order to evaluate Eval(“MyProperty”) statements. This is going to be one of the biggest comparisons in terms of performance between the two models. By minimizing the number of reflection calls, XSLTs get an upper hand here.

  • It is very very easy to write un-tuned xslt files. Proper use of xsl variables can really eliminate many of the iterations required to produce the xml output. If you have a commonly referenced input element, store it in an xsl variable an access it from there.

  • Depending on whether or not you plan on writing your xsl output directly to the response stream. Remember to size your buffers properly. By settings a default buffer size on your transformation MemoryStream’s you save yourself a massive amount of memory allocations (which are generally rather large in the context of an xsl transformation).

  • Although this really comes down to an application level concern. While using XSLT transformations you avoid the whole overhead of control creation, view state serialization, event persistence etc etc etc… Creates a much simpler page life cycle (get data, transform, with a few niceties thrown in between) with should give another edge to an XSLT based system.

Overall, my money is DEFINITELY on a well structures properly implemented XSLT transformation. Especially on a system that has plenty of RAM available for the in memory transformations. I’ve seen XSLT transformations scale to a fairly incredible level, and once a few very key points are learned, it really isn’t that hard to maintain.

Will see if I can remember any others and will edit this post if I do…