Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Xqueeze: Compact XML Alternative
 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 application. -- Robin Berjon <robin.berjon@e...> Research Engineer, Expway http://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
