Every Wednesday I email out the latest article on 4Guys (usually an ASP.NET piece) to those who have signed up for the WebWeekly newsletter. Last week's article was titled Creating XML Documents with the XmlTextWriter Class, and looked at using XmlTextWriter to create XML documents. (You can see a live demo of the XmlTextWriter in use here.) Anywho, after the email went out I got an email from Michael Balloni, the lead software engineer at Steamload.
Streamload is a heavily trafficked Web site that acts as a place for users to store digital content. Users can upload files to Streamload's computers and then download the files or email their files to other Streamload users. To put it mildly, there's a lot of 1s and 0s flying through those pipes leading into Streamload. Since Streamload is located here in sunny San Diego, I've had the opportunity to meet with Michael on more than one occasion. He's showed me around and shown me the code and architecture behind Streamload. Currently, Streamload is still a classic ASP shop. Michael has a rich and efficient architecture built up using classic ASP and VB and C++ COM components that emphasizes efficiency over “the latest technology.” (By the way, Michael has written some articles and user tips on 4Guys...)
Anyway, with that background on Michael and Streamload, you might not be surprised to find out that after reading my article on the XmlTextWriter class, Michael emailed me asking about the performance of XmlTextWriter in comparison to his lightweight XML creating VB6 COM object. His precise comments:
I reckon if you do a straight port to your bloated/overwrought object mess (.NET) that the code won't fare too well...but I also reckon you're crafty enough to rewrite the code to be at least as fast as my VB6 code. I should certainly hope so, don't you think?
A challenge? :-) Unfortunately, my free time is less than ample as of late, so I decided rather than to take this challenge upon myself, I'd offer it up to the ASP.NET/.NET community at large: can you use .NET to beat Michael's implementation? You can get your hands on Michael's VB6 component here. Michael's challenge stands as follows:
Write .NET code to beat my XmlEncode function's "Test Encoding" performance, and use whatever .NET/ASPX method to beat the "Test Throughput" performance (maybe XmlTextWriter will work?) And man, if nobody can do that, jeez.
Anyone up for the challenge?
Personally, I would wager that Michael will win the challenge. Consider, for a moment, this article: XSLT Performance in .NET. In this article author Dan Frumin examines the performance of the MSXML COM component vs. the XslTransform class for performing XSLT transformations. The only speed advantage XslTransform provides is in creation of the object - there is a significant overhead in initializing the COM component in a .NET environment. But, after this initial cost, MSXML kicks butt, especially with larger XML files.
Am I surprised? No. .NET adds on another layer of abstraction onto a programming paradigm already rife with abstractions. The .NET Framework serves as a layer of abstraction, just as the Win32 API serves as a layer of abstraction, just as high-level programming languages serve as a layer of abstraction, just as assembly language serves as a layer of abstraction. .NET, like the Java platform, is another encompassing layer in a slew of layers. Is this a bad thing? Taking a “performance-only” view, then, yes, any layer of abstraction robs you from the sheer performance typing in 1s and 0s can afford. But, from a development standpoint, from looking at the bottom-line not just as how many operations per second, but how many man-hours it takes to create the program to run those operations, layers are a Good Thing.
End conclusion: I expect those who do take on the challenge Michael outlines will have a hard time beating the fine-tuned VB6 COM code. But, in the long run, it really doesn't matter.