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] Xqueeze: Compact XML Alternative

[ Lists Home | Date Index | Thread Index ]

Mike Champion wrote:
> Thus the knee-jerk "XML is too slow" reaction is 
> a bad case of "premature optimization." But what if XML's success 
> creates demand levels that we haven't seen before?  Post-maturity 
> optimization may be necessary :-)

No kidding :) In additions to the cases you quote, you have streaming of XML 
alongside video or radio feeds, random access in humongous documents, 
memory-constrained devices...

> XML databases (and 
> obviously the middleware and applications they support) serving up XML 
> messages/fragments/state thousands of times per second. How sure are we 
> that bandwidth/parsing performance is not a bottleneck in such a scenario?
> (...)I'm sure you'll all be 
> shocked and astonished to hear that Web services invocations of code are 
> slower than native invocations of code, but this indicates that some 
> people are trying to make money in this space.  I'm all for loose 
> coupling, pipelining, platform/language-independence ... but we will be 
> increasingly shown that it comes at a performance cost; the solution is 
> clearly NOT to give up the benefits of these things, but to work to 
> drive down the cost.

I have a patched version of Axis that communicates using binary infosets (in 
Bin-XML/BiM) instead of XML. We didn't have to push it very far to see it go 
faster than the XML version.

> That said, the Xqueeze  approach of using a dictionary based on a pre- 
> arranged schema has been tried repeatedly, no? (e.g. WAP/WML?) Also, 
> that significantly tightens the coupling between the sender and receiver 
> of the XML.  Maybe that is acceptable at the application level, but that 
> middleware that is crunching thousands of XML messages/second isn't 
> going to want to know about every schema of every application that is 
> throwing data at it.

That depends on situations. In the case of Bin-XML, we can encode both schema 
and schema-less documents. Schema-less ones get compression performances at 
least equal to gzip (but parse a lot faster). Schema-aided compression gets much 
better performance (and similar parse times) so that kind of middleware could 
uses schemata as a way to optimize some of the more costly messages. In addition 
to compression, you can have data typing which I helps speed up some types of 

Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488


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

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