Cart
[Home] [By Thread] [By Date] [Recent Entries]
That's a very broad question!
I think probably the most important advice is to use Saxon's native tree model rather than running over the Microsoft DOM (which is possible, but slow). Most of the other things one can say are pretty generic, applying equally to any XSLT processor. It's worth bearing in mind that the Microsoft System.Xml.Xsl processor is one of the fastest in the business. Conversely, Saxon on .NET is cross-compiled from Java and this creates an overhead of about 25%. If you take an XSLT 1.0 stylesheet that works on System.Xml.Xsl and run it unchanged on Saxon, it will probably be slower - not catastrophically slower, but a bit. Another reason for that is that Saxon is optimized for running XSLT 2.0, and some of the "backwards compatibility" features are significantly slower than their 2.0 equivalents. So an important way to get the best out of Saxon when you make the move is to take maximum advantage of XSLT 2.0 and XPath 2.0 features. For example, declaring the types of your variables and parameters gives the Saxon optimizer much more information to play with. The other piece of advice I have to give quite often is that just because you have a performance problem and are using XSLT doesn't mean you have an XSLT performance problem. I usually find that when I look at overall system performance, XSLT transformation plays a rather small role. Often the bottleneck is in preparing the source data for XSLT processing, or in handling of the XSLT result data. On the other hand, I sometimes look at a stylesheet and improve its performance a hundredfold by changing a few lines of code - in a way that is completely independent of which XSLT processor you are using. The moral is, don't worry about tuning your use of the XSLT processor API until you are confident that's where the potential is for overall improvement. Michael Kay Saxonica On 31/08/2010 6:45 PM, Merrilees, David wrote: Hi
|
