Saxon.NET and System.Xml.Xsl

Mike writes about benchmarking Saxon.NET vs System.Xml.Xsl.XslTransform v1.1. .NET seems to be thrice faster, but then Saxon.NET converts .NET DOM into a Saxon tree before each transformation. So Mike went to implement a lightweight wrapper around .NET DOM to allow Saxon to transform .NET DOM almost directly and while working on that he found Microsoft XML documentation "woefully inadequate". Whoha! I know the feeling! Microsoft documentation is written for end users, not for vendors. Just step out a bit from the mainstream (say try to implement custom XmlReader) - and you lost. In too many places MSDN says nothing about how methods behave and even experimenting don't always help. Developing solid software this way sucks a lot. That's a reality I know, but I wish it changes.

Anyway, I should say the benchmark code used isn't an optimal one of course. Transforming to XmlReader never was the fastest method in .NET 1.1. When the result needs to be in DOM, it's better to use XmlNodeWriter to transform directly into DOM. DOM source isn't fastest transformation source either for both .NET and Saxon (did I tell you DOM sucks?) XPathDocument easily gives 30-50% perf improvement. And of course System.Xml.Xsl.XslTransform sucks while System.Xml.Xsl.XslCompiledTransform rocks. That would be interesting to benchmark Saxon.NET with DOM wrapper vs XslCompiledTransform.

But after all Mike is right saying that

Not that Saxon is primarily competing on performance - it's the productivity benefits in XSLT 2.0 that will really influence people - but it would be nice if it's in the same ballpark.

Hey and what about running XslCompiledTransform over XLINQ's XDocument? That should be the killer. Have you seen recent LINQ CTP?