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