[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: performance comparison


sax dom comparison
Title: RE: performance comparison

Jimmy,

I'll provide some quick, basic feedback on #3 below ("why is DOM memory hungry") and defer to others to comment on the rest.  Unlike SAX, the DOM represents an entire XML document in memory in the form of a tree (called the "document tree").  SAX is an event-based API which does not need to build an internal tree.

From the site sax.sourceforge.net:

"Tree-based APIs are useful for a wide range of applications, but they normally put a great strain on system resources, especially if the document is large. Furthermore, many applications need to build their own strongly typed data structures rather than using a generic tree corresponding to an XML document. It is inefficient to build a tree of parse nodes, only to map it onto a new data structure and then discard the original."

"In both of those cases, an event-based API provides a simpler, lower-level access to an XML document: you can parse documents much larger than your available system memory, and you can construct your own data structures using your callback event handlers."

Hope that helps,
Joe Chiusano
LMI

> **************************************************************************
>   Joseph M. Chiusano
>   Logistics Management Institute
>   2000 Corporate Ridge
>   McLean, VA 22102
>   Email: jchiusano@l...
>   Tel: 571.633.7722
> **************************************************************************
>


-----Original Message-----
From: zhengyu@a... [mailto:zhengyu@a...]
Sent: Thursday, July 11, 2002 7:32 PM
To: Xml-dev@l...
Subject: performance comparison


Hello,

 I am evaluting various XML technologies right now.
Although I have used XML before, but in terms of
the real-world performance, I still need help.

  My questions are:

  1.  I have read numerous comparisons between SAX and
DOM, the test benchmarks mostly did straight comparisons
between the two, I think it is very misleading. Am I
right on this? DOM

  2.  Most people mention SAX can handle files larger
than memory, but I am thinking, is this really the case,
because files are read into the kernel buffer, so large
files still have to be read into the memory, just not in
user space. Am I right?

  3. DOM is memory-thirsty, according to most articles I
read. So DOM's performance lags, does anyone run any type
of profiling, and I am interested in why it is memory
hungry, and poor in terms of performance.

  4. What do people think of pull type parsers and DOM
SAX hybrids? Are these popular and stable?

  5. Is it possible for SAX to support XSLT?

Thanks

Jimmy

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.