[
Lists Home |
Date Index |
Thread Index
]
Rich Salz wrote:
>
> One interesting things about client/server XML is that the computing
> load is asymmetric. It's a heck of a lot easier to generate XML than
> it is to consume and process it. Your note didn't seem to take that
> into account.
>
Not sure what you're basing this on, Rich, but it doesn't match what
I've seen. See the results at
http://xbis.sourceforge.net/performance.html, for instance, where
generating text XML from a parse event stream takes on average about the
same amount of time as parsing the text to get back the parse event
stream (ignore the first graphs, which just show a problem in the Sun
JVM, and look at figures 4-6; for this test set parsing is somewhat
slower than writing for larger documents, writing is considerably slower
than parsing for smaller documents). Applications don't have to go
through a parse event stream to generate the XML, of course, but I doubt
that they can get a big advantage by other output techniques - the SAX
parse event stream interface is just basically writing out XML
components, after all. This performance parity also matches what I've
seen with data binding approaches (see
http://www-106.ibm.com/developerworks/library/x-databdopt2/ for examples).
If you're validating the XML against a schema that's a different story;
validation tends to be expensive, and in my experience is not widely
used in production systems. The overhead there would apply where ever
you do the validation (more often on the receiving end, but can be
either or both).
Roger, you may also be interested in my pair of devWorks articles on
"Improving XML Transport Performance" that cover some of the same areas
you've listed:
http://www-106.ibm.com/developerworks/xml/library/x-trans1.html and
http://www-106.ibm.com/developerworks/xml/library/x-trans2/
- Dennis
--
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA 425.885.7197
|
