axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajith Ranabahu <>
Subject Re: [Axis2] OM - Traversal of children from parent
Date Thu, 30 Sep 2004 05:03:20 GMT
Well I should say Chinthaka has a point. The original idea of throwing
away some features of the DOM (at least in the storage) is to reduce
the use of collection classes and improve the memory footprint. some
implementations that are now in the scratch right now go along with
this concept (that is minimize the memory footprint by avoiding the
use of collection classes). I guess that is what Glen refers to as the
"shim DOM"
As far as I understand the thoughts that led to the decision of a
"shim DOM" instead of a full DOM are as follows.
The DOM is to be built by pull parsing in a step-by-step manner. The
objects are created as and when required.
However the advantage gained by this sort of "defered building" can be
deteriorated if the created objects are really heavy. Hence we need a
light weight object representation as well.
So we try to retain what is absolutely necessary to recreate the
infoset of the document. (the parent-to-all-children relationship is
not absolutely necessary. instead the parent has a reference to the
first child and each of the children has a referece to the next
sibling in most of our prototype OMs) This is not really "developer
friendly". It is a fact that higher levels of abstraction provides
less efficient code so if we want to improve the performace then
inevitably we will have to deal with code in a much lower level. So
our OM's lack certain straight-forward accessing methods (such as the
list of children of a parent).
the fact that whether we should have a complete Object structure (such
as DOM or JDOM)  or just a "shim DOM" depends on the kind of documents
we are dealing with. If the documents are huge then a heavy object
structure is disadvantegeous. On the otherhand smaller documents will
be much easier to handle with a full DOM since the memory footprint is
not likely to be a major issue (due to the fact that documents are
smaller and produce fewer objects).
Just as Alek suggests we have to measure the performance and decide
which "optimization" we need.
My guess is Chinthaka is already writing a performace bench based on
the Sosnoski bence mark.

Ajith Ranabahu

View raw message