Speeding XML
For the second time in a row, I am linking to Sun’s website. Sun has posted an article claiming that Java is faster than .NET for processing XML. I was interested in the article, since beside having been the PM for the APIs discussed, I have in the past conducted my own comparisons using Xerces and have always found it to be much slower. I don’t have the code that Sun used to test to verify that it’s a fair comparison, and I don’t have the numbers to judge the reported difference, but I do have a few comments:
- First, it would be a welcome development, if indeed the Java XML processing APIs are finally competetive with .NET on performance. In the past, poor XML performance on Java has been an adoption blocker, and has led Sun to propose solutions like IIOP, RMI, and ASN.1 which have a much higher cost of interoperability. If performance is removed as an adoption blocker, more people can benefit from the interoperability benefits of XML, and everyone wins. Isn’t this what XML is all about?
- Next, although we were very proud of our industry-leading performance when we shipped System.Xml a few years ago, we have always acknowledged that XML has much room for improvement. We feel that the industry should continue to improve and compete on XML performance, and we have put our money on this by investing heavily in performance for our next version of the APIs. We feel that our next release of the APIs, which previewed at PDC, will make huge gains in parsing, generation, and transformation performance; and will again set a bar that will be very difficult for Java to match. And ultimately, we are convinced that this competition and investment in XML performance will prove to yield processing which is far superior to any other alternatives being fronted. We are happy that our investment is validated by this attention from Sun, and we hope that Sun continues to focus on improving and competing in this area rather than attempting to divert customers to complex and proprietary “alternatives” under the guise of better performance.
- Finally, I would agree with Sun’s advice that customers should prototype with both to validate for themselves. I would only suggest that customers prototype with .NET first, and then attempt to prototype with SAX, since the .NET solution will be much quicker to develop and test, and if they are unable to figure out how to get SAX to do what they want, their efforts will not have been in vain.