You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Ajith Ranabahu <aj...@gmail.com> on 2004/12/28 06:29:53 UTC
[Axis2]OM structure
Hi all,
If you look at the code now, the OMAttribute and the OMNamespace are
both detached from the node hierarchy and are standalone now. I
suppose the point is to make them immutable. However this has opend up
some problamatic areas in the implementation.
1. We can no longer use the link lists to store the attributes or the
namespaces. This causes the implementations to use collection classes
(standard or custom) which may increase the memory usage. This is
exactly what we tried to avoid.
2. We still haven't implemented the namespace and attribute
declaration order. Link list will be a very convenient way to do that.
But since attributes and namespaces are not nodes we cannot do that.
I am absolutely -1 for making the changes right now (in time for M1)
but I guess we should at least decide on what kind of structure our OM
should have.
thoughts ?
--
Ajith Ranabahu
Re: [Axis2]OM structure
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Ajith Ranabahu wrote:
>Well, what you speak is the truth. Jdom has done it nicely and it is
>quite user friendly. But the point I am trying to raise here is about
>our model! What is our design principle in OM?
>As far as I rememebr we had several principles
>1. Avoid collection classes. They eat up the memory.
>
>
hi Ajith,
where did this come from - i do not remember this. what test/memory
footprint evaluations do you refer to?
>2. Make it API centric. This is to allow the programmers to have
>multiple implementations under the same API.
>
>
yes
>Unfortunatley JDom's implementation os not API centric, so you don't
>see multiple implementations. DOM is in the other extreme, You have
>only interfaces (in IDL which theoretically you can use to generate
>code in any language)
>My guess is we should decide which side we are :)
>
>
i am on interface side.
alek
>
>On Tue, 28 Dec 2004 15:40:56 +0600, Eran Chinthaka
><ch...@opensource.lk> wrote:
>
>
>>>>start with no collection and allocate collection only if any attribute
>>>>is added and have initial size 1 or 2 with increment of 4.
>>>>
>>>>
>>[Chinthaka] This is what I also have done.
>>Initially there is no collection and if there is an attribute only I create
>>the ArrayList.
>>
>>I just looked in to the JDom way of implementing Namespaces and Attributes.
>>As far as the namespaces are concerned they have done the same thing, we
>>did. They have an ArrayList of 5 to hold namespaces, within the Element.
>>
>>And the same mechanism is there for attributes, but with some more
>>complexity.
>>So I think our approach is not so bad. And I know very well that, JDom is
>>very good in performance wise also, as I used JDom to bench mark our OM.
>>
>>So my opinion is to leave the things as it is, until we find some better way
>>of implementing that.
>>
>>Thankx and regards,
>>-- Eran Chinthaka
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2]OM structure
Posted by Ajith Ranabahu <aj...@gmail.com>.
Well, what you speak is the truth. Jdom has done it nicely and it is
quite user friendly. But the point I am trying to raise here is about
our model! What is our design principle in OM?
As far as I rememebr we had several principles
1. Avoid collection classes. They eat up the memory.
2. Make it API centric. This is to allow the programmers to have
multiple implementations under the same API.
Unfortunatley JDom's implementation os not API centric, so you don't
see multiple implementations. DOM is in the other extreme, You have
only interfaces (in IDL which theoretically you can use to generate
code in any language)
My guess is we should decide which side we are :)
On Tue, 28 Dec 2004 15:40:56 +0600, Eran Chinthaka
<ch...@opensource.lk> wrote:
> >>start with no collection and allocate collection only if any attribute
> >>is added and have initial size 1 or 2 with increment of 4.
>
> [Chinthaka] This is what I also have done.
> Initially there is no collection and if there is an attribute only I create
> the ArrayList.
>
> I just looked in to the JDom way of implementing Namespaces and Attributes.
> As far as the namespaces are concerned they have done the same thing, we
> did. They have an ArrayList of 5 to hold namespaces, within the Element.
>
> And the same mechanism is there for attributes, but with some more
> complexity.
> So I think our approach is not so bad. And I know very well that, JDom is
> very good in performance wise also, as I used JDom to bench mark our OM.
>
> So my opinion is to leave the things as it is, until we find some better way
> of implementing that.
>
> Thankx and regards,
> -- Eran Chinthaka
>
>
--
Ajith Ranabahu
Re: [Axis2]OM structure
Posted by Dasarath Weeratunge <da...@yahoo.com>.
I recall having a discussion on this very matter with
Chanthaka.
Using arrays definitely provides an edge over linked
lists when it comes to random access but the question
does handler's or the provider ever need to query OM
by requesting "give me the 5th header..." "give me the
6th header like..." that. Handlers will all ways
search for headers based on their header name and as
such either the OM or the handler it self will have to
go through all the header blocks. So IMO "random
access" is ABSOLUTELY NOT a reason for going for
collection classes as far as OM is concerned.
--Dasarath
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Eran Chinthaka wrote:
>
> >>>start with no collection and allocate collection
> only if any attribute
> >>>is added and have initial size 1 or 2 with
> increment of 4.
> >>>
> >>>
> >
> > [Chinthaka] This is what I also have done.
> >Initially there is no collection and if there is an
> attribute only I create
> >the ArrayList.
> >
> >
> >I just looked in to the JDom way of implementing
> Namespaces and Attributes.
> >As far as the namespaces are concerned they have
> done the same thing, we
> >did. They have an ArrayList of 5 to hold
> namespaces, within the Element.
> >
> >
> i would guess that if you have 4 or more elements
> than ArrayList is more
> efficient than any linked list implementation
> linked list: N * (size of object) + 2 * N * (size of
> pointer for next/prev)
> array list: N * (size of object) + size filed + N *
> (size of pointer -
> actual array)
> and access is faster as you can read directly
> elements form array no
> need to walk linked list to find elements
>
> however without tests i could not say and moreover i
> think when compared
> to other operations in OM or in Engine this will be
> unnoticeable
>
> alek
>
> >And the same mechanism is there for attributes, but
> with some more
> >complexity.
> >So I think our approach is not so bad. And I know
> very well that, JDom is
> >very good in performance wise also, as I used JDom
> to bench mark our OM.
> >
> >So my opinion is to leave the things as it is,
> until we find some better way
> >of implementing that.
> >
> >
> >Thankx and regards,
> >-- Eran Chinthaka
> >
> >
> >
> >
>
>
> --
> The best way to predict the future is to invent it -
> Alan Kay
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Re: [Axis2]OM structure
Posted by Dasarath Weeratunge <da...@yahoo.com>.
Ppl pls have a look at the performance test results
under:
https://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/dasarath/om/$1/
--Dasarath
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Eran Chinthaka wrote:
>
> >>>start with no collection and allocate collection
> only if any attribute
> >>>is added and have initial size 1 or 2 with
> increment of 4.
> >>>
> >>>
> >
> > [Chinthaka] This is what I also have done.
> >Initially there is no collection and if there is an
> attribute only I create
> >the ArrayList.
> >
> >
> >I just looked in to the JDom way of implementing
> Namespaces and Attributes.
> >As far as the namespaces are concerned they have
> done the same thing, we
> >did. They have an ArrayList of 5 to hold
> namespaces, within the Element.
> >
> >
> i would guess that if you have 4 or more elements
> than ArrayList is more
> efficient than any linked list implementation
> linked list: N * (size of object) + 2 * N * (size of
> pointer for next/prev)
> array list: N * (size of object) + size filed + N *
> (size of pointer -
> actual array)
> and access is faster as you can read directly
> elements form array no
> need to walk linked list to find elements
>
> however without tests i could not say and moreover i
> think when compared
> to other operations in OM or in Engine this will be
> unnoticeable
>
> alek
>
> >And the same mechanism is there for attributes, but
> with some more
> >complexity.
> >So I think our approach is not so bad. And I know
> very well that, JDom is
> >very good in performance wise also, as I used JDom
> to bench mark our OM.
> >
> >So my opinion is to leave the things as it is,
> until we find some better way
> >of implementing that.
> >
> >
> >Thankx and regards,
> >-- Eran Chinthaka
> >
> >
> >
> >
>
>
> --
> The best way to predict the future is to invent it -
> Alan Kay
>
>
__________________________________
Do you Yahoo!?
Jazz up your holiday email with celebrity designs. Learn more.
http://celebrity.mail.yahoo.com
Re: [Axis2]OM structure
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eran Chinthaka wrote:
>>>start with no collection and allocate collection only if any attribute
>>>is added and have initial size 1 or 2 with increment of 4.
>>>
>>>
>
> [Chinthaka] This is what I also have done.
>Initially there is no collection and if there is an attribute only I create
>the ArrayList.
>
>
>I just looked in to the JDom way of implementing Namespaces and Attributes.
>As far as the namespaces are concerned they have done the same thing, we
>did. They have an ArrayList of 5 to hold namespaces, within the Element.
>
>
i would guess that if you have 4 or more elements than ArrayList is more
efficient than any linked list implementation
linked list: N * (size of object) + 2 * N * (size of pointer for next/prev)
array list: N * (size of object) + size filed + N * (size of pointer -
actual array)
and access is faster as you can read directly elements form array no
need to walk linked list to find elements
however without tests i could not say and moreover i think when compared
to other operations in OM or in Engine this will be unnoticeable
alek
>And the same mechanism is there for attributes, but with some more
>complexity.
>So I think our approach is not so bad. And I know very well that, JDom is
>very good in performance wise also, as I used JDom to bench mark our OM.
>
>So my opinion is to leave the things as it is, until we find some better way
>of implementing that.
>
>
>Thankx and regards,
>-- Eran Chinthaka
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
RE: [Axis2]OM structure
Posted by Eran Chinthaka <ch...@opensource.lk>.
>>start with no collection and allocate collection only if any attribute
>>is added and have initial size 1 or 2 with increment of 4.
[Chinthaka] This is what I also have done.
Initially there is no collection and if there is an attribute only I create
the ArrayList.
I just looked in to the JDom way of implementing Namespaces and Attributes.
As far as the namespaces are concerned they have done the same thing, we
did. They have an ArrayList of 5 to hold namespaces, within the Element.
And the same mechanism is there for attributes, but with some more
complexity.
So I think our approach is not so bad. And I know very well that, JDom is
very good in performance wise also, as I used JDom to bench mark our OM.
So my opinion is to leave the things as it is, until we find some better way
of implementing that.
Thankx and regards,
-- Eran Chinthaka
Re: [Axis2]OM structure
Posted by Dasarath Weeratunge <da...@yahoo.com>.
I don't see why namespaces has to be put in a list
b'cos in all other elements except for the one in
which they are defined, only a reference is kept,
anyway.
The case with attributes is tricky. Say if all headers
have MustUnderstand we will need one copy for each
header. Please correct me if I'm wrong but if we use
collection classes we will have a collection object in
each of those elements creating more problems not just
in terms of memory foot print but also in the time
taken for them to be allocated and garbage collected
later on. So IMO I think it would be better to use the
Node architecture still, and clone the attributes
internally when they are added to the tree if they
attached to some other element already. This would be
transparent to the user.
I'm not saying we should not use collection classes. I
think using a linked structure built into the tree
itself would reduce overhead, associated with using
collections. Performance is the key -- if we keep OM
architecture robust and simple we should be able to
get there.
I also don't see why we cannot look at Namespaces as
nodes when DOM takes attributes as Nodes? Its just a
matter of perspective:)
The situation now however is a mess. We should not use
collections for attrs & Ns but not for children. We
need to clean this up and fast!
--Dasarath
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Eran Chinthaka wrote:
>
> >
> >
> >>>On Tue, 28 Dec 2004 11:34:36 +0600, Eran
> Chinthaka
> >>><ch...@opensource.lk> wrote:
> >>>
> >>>
> >>>>[Chinthaka] I had no option but to introduce
> collection classes to store
> >>>>attributes and namespaces, as we detach them
> from Node Structure. And I
> >>>>think that we have to do.
> >>>>
> >>>>
> >>>Yep. Perfectly understandable. But my point is
> whether we should do it
> >>>at the first place. I mean it sort of distorts
> our structure (it has
> >>>made the structure 'inconsistent"). Whatever the
> gain we may have
> >>>received from making the attributes immutable
> would have been
> >>>destroyed by the use of collection classes.
> >>>
> >>>
> >
> > [Chinthaka] I tried to minimize the effect of
> introducing Collections. I
> >used ArrayList and I initialized that to 5,
> initially.
> >
> >But if an OMElement has at least one attribute (or
> one namespace), it has
> >been allocated space for 4 more attributes (or
> namespaces). This has some
> >negative effect for memory foot print.
> >
> >I would like to see some good suggestions, on this.
>
> >
> >
> >
> start with no collection and allocate collection
> only if any attribute
> is added and have initial size 1 or 2 with increment
> of 4.
>
> moreover you can use LinkedList and compare memory
> footprint.
>
> LinkedList should be as good as directly linking
> nodes with prev/next
> pointers especially if String is allowed as direct
> child of Node.
>
> alek
>
> --
> The best way to predict the future is to invent it -
> Alan Kay
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Re: [Axis2]OM structure
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eran Chinthaka wrote:
>
>
>>>On Tue, 28 Dec 2004 11:34:36 +0600, Eran Chinthaka
>>><ch...@opensource.lk> wrote:
>>>
>>>
>>>>[Chinthaka] I had no option but to introduce collection classes to store
>>>>attributes and namespaces, as we detach them from Node Structure. And I
>>>>think that we have to do.
>>>>
>>>>
>>>Yep. Perfectly understandable. But my point is whether we should do it
>>>at the first place. I mean it sort of distorts our structure (it has
>>>made the structure 'inconsistent"). Whatever the gain we may have
>>>received from making the attributes immutable would have been
>>>destroyed by the use of collection classes.
>>>
>>>
>
> [Chinthaka] I tried to minimize the effect of introducing Collections. I
>used ArrayList and I initialized that to 5, initially.
>
>But if an OMElement has at least one attribute (or one namespace), it has
>been allocated space for 4 more attributes (or namespaces). This has some
>negative effect for memory foot print.
>
>I would like to see some good suggestions, on this.
>
>
>
start with no collection and allocate collection only if any attribute
is added and have initial size 1 or 2 with increment of 4.
moreover you can use LinkedList and compare memory footprint.
LinkedList should be as good as directly linking nodes with prev/next
pointers especially if String is allowed as direct child of Node.
alek
--
The best way to predict the future is to invent it - Alan Kay
RE: [Axis2]OM structure
Posted by Eran Chinthaka <ch...@opensource.lk>.
>>
>>On Tue, 28 Dec 2004 11:34:36 +0600, Eran Chinthaka
>><ch...@opensource.lk> wrote:
>>>
>>
>>> [Chinthaka] I had no option but to introduce collection classes to store
>>> attributes and namespaces, as we detach them from Node Structure. And I
>>> think that we have to do.
>>
>>Yep. Perfectly understandable. But my point is whether we should do it
>>at the first place. I mean it sort of distorts our structure (it has
>>made the structure 'inconsistent"). Whatever the gain we may have
>>received from making the attributes immutable would have been
>>destroyed by the use of collection classes.
[Chinthaka] I tried to minimize the effect of introducing Collections. I
used ArrayList and I initialized that to 5, initially.
But if an OMElement has at least one attribute (or one namespace), it has
been allocated space for 4 more attributes (or namespaces). This has some
negative effect for memory foot print.
I would like to see some good suggestions, on this.
-- Eran Chinthaka
Re: [Axis2]OM structure
Posted by Ajith Ranabahu <aj...@gmail.com>.
On Tue, 28 Dec 2004 11:34:36 +0600, Eran Chinthaka
<ch...@opensource.lk> wrote:
>
> [Chinthaka] I had no option but to introduce collection classes to store
> attributes and namespaces, as we detach them from Node Structure. And I
> think that we have to do.
Yep. Perfectly understandable. But my point is whether we should do it
at the first place. I mean it sort of distorts our structure (it has
made the structure 'inconsistent"). Whatever the gain we may have
received from making the attributes immutable would have been
destroyed by the use of collection classes.
>
>
> [Chinthaka] This I will implement, after M1.
>
> >>I am absolutely -1 for making the changes right now
>
> [Chinthaka] me too.
>
--
Ajith Ranabahu
RE: [Axis2]OM structure
Posted by Eran Chinthaka <ch...@opensource.lk>.
>>Hi all,
>>If you look at the code now, the OMAttribute and the OMNamespace are
>>both detached from the node hierarchy and are standalone now. I
>>suppose the point is to make them immutable. However this has opend up
>>some problamatic areas in the implementation.
>>1. We can no longer use the link lists to store the attributes or the
>>namespaces. This causes the implementations to use collection classes
>>(standard or custom) which may increase the memory usage. This is
>>exactly what we tried to avoid.
[Chinthaka] I had no option but to introduce collection classes to store
attributes and namespaces, as we detach them from Node Structure. And I
think that we have to do.
>>2. We still haven't implemented the namespace and attribute
>>declaration order. Link list will be a very convenient way to do that.
>>But since attributes and namespaces are not nodes we cannot do that.
>>
[Chinthaka] This I will implement, after M1.
>>I am absolutely -1 for making the changes right now
[Chinthaka] me too.
-- Eran Chinthaka
(in time for M1)
>>but I guess we should at least decide on what kind of structure our OM
>>should have.
>>
>>thoughts ?
>>
>>--
>>Ajith Ranabahu