Properly utilizing XslCompiledTransform
Not long ago, we noticed some degradation in performance after we upgraded to .NET 2.0 and migrated to the XslCompiledTransform class from the now obsolete XslTransform class. Our implementation was fairly straightforward, although we hid it behind an interface for easy mocking/testing.
The code looked something like the below:
public interface TransformLoader { XslCompiledTransform Load(string name); } class XslTransformLoader : TransformLoader { public XslCompiledTransform Load(string name) { XslCompiledTransform transform = new XslCompiledTransform(); transform.Load(name); return transform; } }
This is a pretty standard implementation, although after JetBrains .Trace pointed out that a majority of the time was being spent in the Load method, we started doing some research. As it turns out, we mistakenly understood the XslCompiledTransform to be smart enough to determine whether or not the transform had already been compiled. If it was, we thought, it would use the compiled version. As it turns out, this is not the case. To effectively utilize this class, it is important to save off the instance of the class for subsequent uses.
To do this, we created a new implementation, the CachedXslTransformLoader, which looks like this:
class CachedXslTransformLoader : TransformLoader { private Dictionary<string, XslCompiledTransform> transforms = new Dictionary<string, XslCompiledTransform>(); public XslCompiledTransform Load(string name) { XslCompiledTransform transform = null; if (!transforms.TryGetValue(name, out transform)) { transform = new XslCompiledTransform(); transform.Load(name); transforms[name] = transform; } return transform; } }
When running the older XslTransformLoader through a loop of 100 transformations with our XSLT and XML files, we found that it was taking approximately 48 seconds to transform the entire loop. However, when utilizing the new CachedXslTransformLoader, the exact same loop only took 1.3 seconds to execute.
This is where the performance improvements from the XslCompiledTransform really come to fruition, so make sure that you are saving off the instance of the class. As we saw, the class is not smart enough to determine whether or not the XSL has already been compiled.
By the way, the performance problem we were experiencing went away with this minor change. On another note, it was nice to see this adhere to the open/closed principle. We were able to correct issues in the system by adding new code, not by touching existing/tested code.
Bottom line: when using XslCompiledTransform, make sure to save off the instance and reuse it for maximum performance benefit.
Thank you for sharing this tip. How are you creating an instance of CachedXslTransformLoader so that it is available everywhere it is needed? For instance, we use XSL heavily to handle website navigation and would want this object to be available to all requests, site-wide.
Options I’ve considered include marking the Dictionary as static but that seems like a bad idea because it’ll make it available server wide, not site-wide (which could have negative affects on a shared host).
Another option might be to define an instance in the Application_OnStart method and then pass that in as a dependency to the method(s) we use for xml/xsl processing.
Thoughts?
@kyle: Our applications use Castle Windsor for dependency injection, so that is how we’re using that. It’s default lifecycle works perfectly for this type of thing. If you’re not using an IoC container, defining it in your application class and then using it that way would work as well.


