OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Binary XML == "spawn of the devil" ?

[ Lists Home | Date Index | Thread Index ]

Elliotte Rusty Harold wrote:

>One of the goals of some of the developers pushing binary XML is to 
>speed up parsing, to provide some sort of preparsed format that is 
>quicker to parse than real XML. I am extremely skeptical that this 
>can be achieved in a platform-independent fashion. Possibly some of 
>the ideas for writing length codes into the data might help, though I 
>doubt they help that much, or are robust in the face of data that 
>violates the length codes.  Nonetheless this is at least plausible.
I'm getting a several times (2-4X) performance improvement using my XMLS 
format (http://www.sosnoski.com/opensrc/xmls), as compared to SAX2 
parsing of text. This is using an updated version of the code that 
includes a SAX2 handler. The code isn't optimized for this purpose yet 
(it's unnecessarily converting all character data to and from String 
objects for the SAX2 interface), so the end results may be better than 
what I've seen so far. I'll get this completed and post the code along 
with updated test results to Sourceforge within the next month.

So far I've looked at several types of documents including both 
data-centric (such as your own periodic_table.xml) and document-centric 
(the XML specification, with the external DTD brought inline to minimize 
parser overhead), compared with both Xerces and Piccolo parsers, and 
tried both IBM and Sun JVMs for Linux, all without much overall 
variation in the results.

For data-centric documents I suspect a lot of the benefit comes from 
reducing the document size - the XMLS format is generally about 60-80% 
smaller than text for the documents I've tested. The size benefits are 
even greater when multiple documents of the same type are included in a 
single stream. For the XML spec there's only a relatively small size 
reduction, though (17%), so I don't know why the performance is still 
much better in this case.

Generating XMLS is also very fast. I've been using David Megginson's 
XMLWriter for comparison (since it uses a SAX2 interface) and finding 
that here again the XMLS generation code is several times faster (4-8X). 
XMLWriter isn't really optimized for speed, though, so if anyone can 
suggest a faster way of generating text from a SAX2 event source I'll 
gladly try that instead.

  - Dennis

Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
Redmond, WA  425.885.7197


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS