OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: efficient XML


<Matt>

> Hierarchy makes sense, recursion doesn't.  Recursion often causes more
> memory to be used during a parse because information relating to an
> element's extended family needs to be kept.  Of course, a hierarchy can be
> recursive, which is good for a DOM-based approach (finding the value of an
> element in a logical order), but it is less useful to an event based
parser.
</Matt>

<Betty>
	Recursion is useful in lots of applications. If you look at a
comprehensive parts catalog, where you have a component that has attaching
parts which have attaching parts.  You want to model the component and
allow the user to drill-down to the necessary part.  You cannot
semantically identify the levels of attaching parts.  XML provides
this facility very nicely.
</Betty>

The key point I was striving at is "un-necessary recursiveness".  Extraneous
element inclusion should be avoided if doing so doesn't effect semantic
context.  A parser/handler can uniquely distinguish the following nodes fine
either way but the latter builds a smaller memory structure:

Example A:

<dwelling>
   <house>
      <My>nice</My>
      <Your>ugly</Your>
   <house>
</dwelling>

Example B:

<dwelling>
   <MyHouse>nice</MyHouse>
   <YourHouse>ugly</YourHouse>
</dwelling>

Here is why:

The first (Example A) must built a DOM structure that includes a path for
all possible node access.  There are 4 possible paths to nodes -

//dwelling
//dwelling/house
//dwelling/house/My
//dwelling/house/Your

The second (Example B) only needs 3:

//dwelling
//dwelling/MyHouse
//dwelling/YourHouse

Now imagine an XML input tree with over 1000 nodesets.  Each time a
processor tries to find specific information by traversing the tree, it has
to chug along through 25% more iterations before it checks all the nodes.
It also has to build a larger set of paths in memory therfore taking up more
memory.

Sax parsing can mitigate some of this impact because it uses a streaming
approach.  It is still unclear how recursion effects SAX parser/handler
performance.

My $0.02 worth.

Duane Nickull






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC