This week I spent some time with the excellent Jet Brains dotTrace Profiler, which allows you to see exactly how many milliseconds every method of your code is taking. I found the performance profiling quite easy to use, and within a few minutes I had already isolated a few problem areas in our application.
One of the main trouble spots I came across was with the XslCompiledTransform class, which replaces the new obsolete XsltTransform class. This class, new to .net 2.0, performs way faster because it actually loads and compiles the xslt into MSIL. We rely heavily on xslts in our applications, with almost all html being defined in xslts instead of embedded inside app code. I’ll go into detail on this in a future post.
Using the profiler, I was noticing that loading xslt into XslCompiledTransform was taking a good 30-35% of the processing time for a page, since it is actually compiling the xslt on the fly. The solution? Either use caching, or make the compiled transform static, so that it reuses the same one instead of constantly recompiling it.
You may find my notes on httpcontext.cache helpful.
0 Responses to “optimizing XSL in .NET 2.0”