May 12, 2006

On experimenting with LINQ CTP without screwing up Visual Studio (C# only)

LINQ May 2006 CTP installs C# 3.0 compiler and new C# language service into Visual Studio 2005. New syntax, keywords, Intellisense for extension methods and all that jazz. This essensially disables native C# 2.0 compiler and C# language service. If you installed LINQ on Virtual PC - big deal. But ...

May 11, 2006

Saxon.NET and System.Xml.Xsl

I really enjoy seeing Michael Kay talking about working with XML in .NET. That makes me feel I might be not a freak after all. ...

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?

May 8, 2006

VB LINQ: getting a bit closer to C# a bit further from SQL

According to Paul Vick VB9 LINQ query syntax will be switched from SQL-like "Select/From" to "From/Select" (Paul calls it "Yoda style" :) used by C# since the begining of LINQ. While for VB it's quite natural to follow SQL syntax (so not troubling poor busy VB developers), working Intellisense is ...