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 Steve Green <st...@epok.net> on 2004/10/13 23:51:58 UTC
Axis performance and MessageElement.equals()
Developers,
I've been doing some performance profiling and I stumbled into
MessageElement.equals(). Is there any reason why the equals method
needs to compare strings? Can it not just compare the objects?
The reason I ask is because of because of NodeImpl. NodeImpl keeps an
ArrayList of children. Many of the operations in NodeImpl use
ArrayList.indexOf() which calls equals(). Isn't it the case that
removeChild(), insertBefore(), etc... should be looking for a specific
object, not an object that looks the same? While we're at it, shouldn't
removeChild() return after finding the child? Currently, it continues
to search for more children that equals() the child to remove. The DOM
documents are not clear on this.
Thank you.
~S
Re: Axis performance and MessageElement.equals()
Posted by Jongjin Choi <gu...@hotmail.com>.
Nishant,
I think this is a Good change
The current equals() impl in MessageElement may cause some problem.
IMO, after all, refactoring of NodeImpl will be need.
The linked-list based OM impl of Axis2 looks like a appropriate solution.
Jongjin/
----- Original Message -----
From: "Nishant Kumar" <ni...@itellix.com>
To: <ax...@ws.apache.org>
Sent: Thursday, October 14, 2004 2:29 PM
Subject: Re: Axis performance and MessageElement.equals()
> hi,
> this is exactly the second point i have mentioned at
> http://nishantkumar.com/notes/tuning/axis.html.
>
> I have also suggested a simple solution for this which will apply for
> most of the situations.
> this time i am attaching a patch for
> src/org/apache/axis/message/NodeImpl.java and
> src/org/apache/axis/message/MessageElement.java
>
> these two patches will solve the problem, most of the time. this will
> surely boost performance.
> you can have look at these patches to find out what i mean by most of the time.
>
> i will attach these patches in
> http://issues.apache.org/jira/browse/AXIS-1497 too.
>
> thanks,
> nishant
>
> On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > Developers,
> >
> > I've been doing some performance profiling and I stumbled into
> > MessageElement.equals(). Is there any reason why the equals method
> > needs to compare strings? Can it not just compare the objects?
> >
> > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > ArrayList of children. Many of the operations in NodeImpl use
> > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > removeChild(), insertBefore(), etc... should be looking for a specific
> > object, not an object that looks the same? While we're at it, shouldn't
> > removeChild() return after finding the child? Currently, it continues
> > to search for more children that equals() the child to remove. The DOM
> > documents are not clear on this.
> >
> > Thank you.
> >
> > ~S
> >
>
Re: Axis performance and MessageElement.equals()
Posted by Nishant Kumar <ni...@itellix.com>.
hi Peter,
I am an onlooker myself. pop/push should be balanced when you have
logic built into the cache to check that the cached element start from a
consistent state.
for example, whenever you use a database connection pool, you always
need to specify the validation query. the db pool has logic built into
it to test the connection even in cases of failures and exceptions.
anyway here there is no business need to keep the document builder
cached for ever. this was implemented just for performance sake. So
there is no harm in not caching a document builder which has thrown an
exception while creating a new document. And now I guess i have some
company in Jongjin. :)
as far as the question about the exception that newDocument method can
throw, it can throw any runtime exception. So tomorrow i can write my
own parser that may throw a runtime exception in this method.
thanks,
nishant
On Mon, 2004-10-18 at 05:00, Peter Smith wrote:
> I suggested the try/finally in AXIS-1597. I was curious if db.newDocument()
> throws an exception what has that to do with the db? How does it differ from
> the db.parse(inp) scenario in newDocument(InputSource inp) or was the
> try/finally removed from that code also? I am just an onlooker who thinks
> not enforcing a balanced pop/push in a cache is unusual.
>
> Peter.
>
> ----- Original Message -----
> From: "Jongjin Choi" <gu...@hotmail.com>
> To: <ax...@ws.apache.org>
> Sent: Sunday, October 17, 2004 9:40 PM
> Subject: Re: Axis performance and MessageElement.equals()
>
>
> > Nishant,
> >
> > I think the point is that if some exception occurs while creating a new
> document from DocumentBuilder,
> > what should we do for the DocumentBuilder. Do I catch your point?
> >
> > I did not experience that exceptional situation and do not know the JAXP
> internals well,
> > so I can not tell the right opinion.
> >
> > But I think it is better to discard the document builder as you said.
> > That's my 2 cents.
> >
> > Thanks.
> >
> > PS.
> > I am not a committer for the Axis project, just contributing some patches
> and ideas.
> > So I can't apply your patch directly. :-)
> >
> >
> >
> > ----- Original Message -----
> > From: "Nishant Kumar" <ni...@itellix.com>
> > To: <di...@apache.org>
> > Cc: "axisdev" <ax...@ws.apache.org>
> > Sent: Sunday, October 17, 2004 6:00 PM
> > Subject: Re: Axis performance and MessageElement.equals()
> >
> >
> > > hi dims,
> > > I guess that Jongjin had suggested this change so may be he can review
> > > this patch. I have the removed the try and the finally bocks, that's it.
> > > attaching the patch again.
> > > thanks,
> > > nishant
> > >
> > >
> > > On Fri, 2004-10-15 at 18:56, Davanum Srinivas wrote:
> > > > Pls check the patch...it just removes a bunch of lines :(
> > > >
> > > > -- dims
> > > >
> > > >
> > > > On 15 Oct 2004 18:45:50 +0530, Nishant Kumar
> <ni...@itellix.com> wrote:
> > > > > you do release document builder to the cache but not when you get an
> > > > > exception. when you get an exception you cannot be sure that the
> > > > > document builder is in perfect state so better create a new one next
> > > > > time. in the normal case (which will be far more than the
> exceptional
> > > > > one) after creating the document object you can return the document
> > > > > builder to its cache. i have done the same in the patch.
> > > > >
> > > > > thanks,
> > > > >
> > > > >
> > > > > nishant
> > > > >
> > > > > On Fri, 2004-10-15 at 17:54, Davanum Srinivas wrote:
> > > > > > Nishant,
> > > > > >
> > > > > > Am confused....What's the point of having a cache of
> DocumentBuilders
> > > > > > if you don't release it back into the cache?
> > > > > >
> > > > > > -- dims
> > > > > >
> > > > > > On 15 Oct 2004 16:55:26 +0530, Nishant Kumar
> <ni...@itellix.com> wrote:
> > > > > > > hi,
> > > > > > > sorry, i meant we should NOT be releasing the documentbuilder in
> the
> > > > > > > finally clause. we can just discard the builder if there is any
> > > > > > > exception. kindly have a look at the attached patch. this
> suggestion is
> > > > > > > based on the latest from the cvs.
> > > > > > >
> > > > > > >
> > > > > > > bye for now,
> > > > > > > nishant
> > > > > > >
> > > > > > > On Fri, 2004-10-15 at 15:40, Davanum Srinivas wrote:
> > > > > > > > Nishant,
> > > > > > > > check the latest CVS :)
> > > > > > > >
> > > > > > > > -- dims
> > > > > > > >
> > > > > > > >
> > > > > > > > On 15 Oct 2004 10:13:47 +0530, Nishant Kumar
> <ni...@itellix.com> wrote:
> > > > > > > > > hi Jongjin,
> > > > > > > > > can you make a slight change to XMLUtils. I think we
> should be
> > > > > > > > > releasing the documentbuilder in the finally clause. May be,
> we can just
> > > > > > > > > discard the document builder if there is an exception. You
> can have a
> > > > > > > > > look at the attached patch.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > thanks,
> > > > > > > > > nishant
> > > > > > > > > On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> > > > > > > > > > Jongjin,
> > > > > > > > > >
> > > > > > > > > > AXIS-1597 should be fixed now.
> > > > > > > > > >
> > > > > > > > > > -- dims
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi
> <gu...@hotmail.com> wrote:
> > > > > > > > > > > Nishant,
> > > > > > > > > > >
> > > > > > > > > > > I reviewed your note at
> http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > > > > I think the third point in your note, 'ThreadLocal for
> DocumentBuilder' is related to the jira issue AXIS-1597.
> > > > > > > > > > > In AXIS-1597, I mentioned another way to reuse the
> DocumentBuilder.
> > > > > > > > > > >
> > > > > > > > > > > Using this way, I think Axis can serve all threads with
> fewer number of DocumentBuilder compared to per-thread model.
> > > > > > > > > > >
> > > > > > > > > > > What do you think about that?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Jongjin/
> > > > > > > > > > >
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Nishant Kumar" <ni...@itellix.com>
> > > > > > > > > > > To: <ax...@ws.apache.org>
> > > > > > > > > > > Sent: Thursday, October 14, 2004 2:29 PM
> > > > > > > > > > > Subject: Re: Axis performance and
> MessageElement.equals()
> > > > > > > > > > >
> > > > > > > > > > > > hi,
> > > > > > > > > > > > this is exactly the second point i have mentioned at
> > > > > > > > > > > > http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > > > > >
> > > > > > > > > > > > I have also suggested a simple solution for this which
> will apply for
> > > > > > > > > > > > most of the situations.
> > > > > > > > > > > > this time i am attaching a patch for
> > > > > > > > > > > > src/org/apache/axis/message/NodeImpl.java and
> > > > > > > > > > > > src/org/apache/axis/message/MessageElement.java
> > > > > > > > > > > >
> > > > > > > > > > > > these two patches will solve the problem, most of the
> time. this will
> > > > > > > > > > > > surely boost performance.
> > > > > > > > > > > > you can have look at these patches to find out what i
> mean by most of the time.
> > > > > > > > > > > >
> > > > > > > > > > > > i will attach these patches in
> > > > > > > > > > > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > > > > > > > > > > >
> > > > > > > > > > > > thanks,
> > > > > > > > > > > > nishant
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > > > > > > > > > > Developers,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I've been doing some performance profiling and I
> stumbled into
> > > > > > > > > > > > > MessageElement.equals(). Is there any reason why
> the equals method
> > > > > > > > > > > > > needs to compare strings? Can it not just compare
> the objects?
> > > > > > > > > > > > >
> > > > > > > > > > > > > The reason I ask is because of because of NodeImpl.
> NodeImpl keeps an
> > > > > > > > > > > > > ArrayList of children. Many of the operations in
> NodeImpl use
> > > > > > > > > > > > > ArrayList.indexOf() which calls equals(). Isn't it
> the case that
> > > > > > > > > > > > > removeChild(), insertBefore(), etc... should be
> looking for a specific
> > > > > > > > > > > > > object, not an object that looks the same? While
> we're at it, shouldn't
> > > > > > > > > > > > > removeChild() return after finding the child?
> Currently, it continues
> > > > > > > > > > > > > to search for more children that equals() the child
> to remove. The DOM
> > > > > > > > > > > > > documents are not clear on this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thank you.
> > > > > > > > > > > > >
> > > > > > > > > > > > > ~S
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
>
> If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
>
>
Re: Axis performance and MessageElement.equals()
Posted by Peter Smith <pe...@fast.fujitsu.com.au>.
I suggested the try/finally in AXIS-1597. I was curious if db.newDocument()
throws an exception what has that to do with the db? How does it differ from
the db.parse(inp) scenario in newDocument(InputSource inp) or was the
try/finally removed from that code also? I am just an onlooker who thinks
not enforcing a balanced pop/push in a cache is unusual.
Peter.
----- Original Message -----
From: "Jongjin Choi" <gu...@hotmail.com>
To: <ax...@ws.apache.org>
Sent: Sunday, October 17, 2004 9:40 PM
Subject: Re: Axis performance and MessageElement.equals()
> Nishant,
>
> I think the point is that if some exception occurs while creating a new
document from DocumentBuilder,
> what should we do for the DocumentBuilder. Do I catch your point?
>
> I did not experience that exceptional situation and do not know the JAXP
internals well,
> so I can not tell the right opinion.
>
> But I think it is better to discard the document builder as you said.
> That's my 2 cents.
>
> Thanks.
>
> PS.
> I am not a committer for the Axis project, just contributing some patches
and ideas.
> So I can't apply your patch directly. :-)
>
>
>
> ----- Original Message -----
> From: "Nishant Kumar" <ni...@itellix.com>
> To: <di...@apache.org>
> Cc: "axisdev" <ax...@ws.apache.org>
> Sent: Sunday, October 17, 2004 6:00 PM
> Subject: Re: Axis performance and MessageElement.equals()
>
>
> > hi dims,
> > I guess that Jongjin had suggested this change so may be he can review
> > this patch. I have the removed the try and the finally bocks, that's it.
> > attaching the patch again.
> > thanks,
> > nishant
> >
> >
> > On Fri, 2004-10-15 at 18:56, Davanum Srinivas wrote:
> > > Pls check the patch...it just removes a bunch of lines :(
> > >
> > > -- dims
> > >
> > >
> > > On 15 Oct 2004 18:45:50 +0530, Nishant Kumar
<ni...@itellix.com> wrote:
> > > > you do release document builder to the cache but not when you get an
> > > > exception. when you get an exception you cannot be sure that the
> > > > document builder is in perfect state so better create a new one next
> > > > time. in the normal case (which will be far more than the
exceptional
> > > > one) after creating the document object you can return the document
> > > > builder to its cache. i have done the same in the patch.
> > > >
> > > > thanks,
> > > >
> > > >
> > > > nishant
> > > >
> > > > On Fri, 2004-10-15 at 17:54, Davanum Srinivas wrote:
> > > > > Nishant,
> > > > >
> > > > > Am confused....What's the point of having a cache of
DocumentBuilders
> > > > > if you don't release it back into the cache?
> > > > >
> > > > > -- dims
> > > > >
> > > > > On 15 Oct 2004 16:55:26 +0530, Nishant Kumar
<ni...@itellix.com> wrote:
> > > > > > hi,
> > > > > > sorry, i meant we should NOT be releasing the documentbuilder in
the
> > > > > > finally clause. we can just discard the builder if there is any
> > > > > > exception. kindly have a look at the attached patch. this
suggestion is
> > > > > > based on the latest from the cvs.
> > > > > >
> > > > > >
> > > > > > bye for now,
> > > > > > nishant
> > > > > >
> > > > > > On Fri, 2004-10-15 at 15:40, Davanum Srinivas wrote:
> > > > > > > Nishant,
> > > > > > > check the latest CVS :)
> > > > > > >
> > > > > > > -- dims
> > > > > > >
> > > > > > >
> > > > > > > On 15 Oct 2004 10:13:47 +0530, Nishant Kumar
<ni...@itellix.com> wrote:
> > > > > > > > hi Jongjin,
> > > > > > > > can you make a slight change to XMLUtils. I think we
should be
> > > > > > > > releasing the documentbuilder in the finally clause. May be,
we can just
> > > > > > > > discard the document builder if there is an exception. You
can have a
> > > > > > > > look at the attached patch.
> > > > > > > >
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > > nishant
> > > > > > > > On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> > > > > > > > > Jongjin,
> > > > > > > > >
> > > > > > > > > AXIS-1597 should be fixed now.
> > > > > > > > >
> > > > > > > > > -- dims
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi
<gu...@hotmail.com> wrote:
> > > > > > > > > > Nishant,
> > > > > > > > > >
> > > > > > > > > > I reviewed your note at
http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > > > I think the third point in your note, 'ThreadLocal for
DocumentBuilder' is related to the jira issue AXIS-1597.
> > > > > > > > > > In AXIS-1597, I mentioned another way to reuse the
DocumentBuilder.
> > > > > > > > > >
> > > > > > > > > > Using this way, I think Axis can serve all threads with
fewer number of DocumentBuilder compared to per-thread model.
> > > > > > > > > >
> > > > > > > > > > What do you think about that?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Jongjin/
> > > > > > > > > >
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Nishant Kumar" <ni...@itellix.com>
> > > > > > > > > > To: <ax...@ws.apache.org>
> > > > > > > > > > Sent: Thursday, October 14, 2004 2:29 PM
> > > > > > > > > > Subject: Re: Axis performance and
MessageElement.equals()
> > > > > > > > > >
> > > > > > > > > > > hi,
> > > > > > > > > > > this is exactly the second point i have mentioned at
> > > > > > > > > > > http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > > > >
> > > > > > > > > > > I have also suggested a simple solution for this which
will apply for
> > > > > > > > > > > most of the situations.
> > > > > > > > > > > this time i am attaching a patch for
> > > > > > > > > > > src/org/apache/axis/message/NodeImpl.java and
> > > > > > > > > > > src/org/apache/axis/message/MessageElement.java
> > > > > > > > > > >
> > > > > > > > > > > these two patches will solve the problem, most of the
time. this will
> > > > > > > > > > > surely boost performance.
> > > > > > > > > > > you can have look at these patches to find out what i
mean by most of the time.
> > > > > > > > > > >
> > > > > > > > > > > i will attach these patches in
> > > > > > > > > > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > > > > > > > > > >
> > > > > > > > > > > thanks,
> > > > > > > > > > > nishant
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > > > > > > > > > Developers,
> > > > > > > > > > > >
> > > > > > > > > > > > I've been doing some performance profiling and I
stumbled into
> > > > > > > > > > > > MessageElement.equals(). Is there any reason why
the equals method
> > > > > > > > > > > > needs to compare strings? Can it not just compare
the objects?
> > > > > > > > > > > >
> > > > > > > > > > > > The reason I ask is because of because of NodeImpl.
NodeImpl keeps an
> > > > > > > > > > > > ArrayList of children. Many of the operations in
NodeImpl use
> > > > > > > > > > > > ArrayList.indexOf() which calls equals(). Isn't it
the case that
> > > > > > > > > > > > removeChild(), insertBefore(), etc... should be
looking for a specific
> > > > > > > > > > > > object, not an object that looks the same? While
we're at it, shouldn't
> > > > > > > > > > > > removeChild() return after finding the child?
Currently, it continues
> > > > > > > > > > > > to search for more children that equals() the child
to remove. The DOM
> > > > > > > > > > > > documents are not clear on this.
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you.
> > > > > > > > > > > >
> > > > > > > > > > > > ~S
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
Re: Axis performance and MessageElement.equals()
Posted by Jongjin Choi <gu...@hotmail.com>.
Nishant,
I think the point is that if some exception occurs while creating a new document from DocumentBuilder,
what should we do for the DocumentBuilder. Do I catch your point?
I did not experience that exceptional situation and do not know the JAXP internals well,
so I can not tell the right opinion.
But I think it is better to discard the document builder as you said.
That's my 2 cents.
Thanks.
PS.
I am not a committer for the Axis project, just contributing some patches and ideas.
So I can't apply your patch directly. :-)
----- Original Message -----
From: "Nishant Kumar" <ni...@itellix.com>
To: <di...@apache.org>
Cc: "axisdev" <ax...@ws.apache.org>
Sent: Sunday, October 17, 2004 6:00 PM
Subject: Re: Axis performance and MessageElement.equals()
> hi dims,
> I guess that Jongjin had suggested this change so may be he can review
> this patch. I have the removed the try and the finally bocks, that's it.
> attaching the patch again.
> thanks,
> nishant
>
>
> On Fri, 2004-10-15 at 18:56, Davanum Srinivas wrote:
> > Pls check the patch...it just removes a bunch of lines :(
> >
> > -- dims
> >
> >
> > On 15 Oct 2004 18:45:50 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > > you do release document builder to the cache but not when you get an
> > > exception. when you get an exception you cannot be sure that the
> > > document builder is in perfect state so better create a new one next
> > > time. in the normal case (which will be far more than the exceptional
> > > one) after creating the document object you can return the document
> > > builder to its cache. i have done the same in the patch.
> > >
> > > thanks,
> > >
> > >
> > > nishant
> > >
> > > On Fri, 2004-10-15 at 17:54, Davanum Srinivas wrote:
> > > > Nishant,
> > > >
> > > > Am confused....What's the point of having a cache of DocumentBuilders
> > > > if you don't release it back into the cache?
> > > >
> > > > -- dims
> > > >
> > > > On 15 Oct 2004 16:55:26 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > > > > hi,
> > > > > sorry, i meant we should NOT be releasing the documentbuilder in the
> > > > > finally clause. we can just discard the builder if there is any
> > > > > exception. kindly have a look at the attached patch. this suggestion is
> > > > > based on the latest from the cvs.
> > > > >
> > > > >
> > > > > bye for now,
> > > > > nishant
> > > > >
> > > > > On Fri, 2004-10-15 at 15:40, Davanum Srinivas wrote:
> > > > > > Nishant,
> > > > > > check the latest CVS :)
> > > > > >
> > > > > > -- dims
> > > > > >
> > > > > >
> > > > > > On 15 Oct 2004 10:13:47 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > > > > > > hi Jongjin,
> > > > > > > can you make a slight change to XMLUtils. I think we should be
> > > > > > > releasing the documentbuilder in the finally clause. May be, we can just
> > > > > > > discard the document builder if there is an exception. You can have a
> > > > > > > look at the attached patch.
> > > > > > >
> > > > > > >
> > > > > > > thanks,
> > > > > > > nishant
> > > > > > > On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> > > > > > > > Jongjin,
> > > > > > > >
> > > > > > > > AXIS-1597 should be fixed now.
> > > > > > > >
> > > > > > > > -- dims
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi <gu...@hotmail.com> wrote:
> > > > > > > > > Nishant,
> > > > > > > > >
> > > > > > > > > I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > > I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> > > > > > > > > In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
> > > > > > > > >
> > > > > > > > > Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
> > > > > > > > >
> > > > > > > > > What do you think about that?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Jongjin/
> > > > > > > > >
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Nishant Kumar" <ni...@itellix.com>
> > > > > > > > > To: <ax...@ws.apache.org>
> > > > > > > > > Sent: Thursday, October 14, 2004 2:29 PM
> > > > > > > > > Subject: Re: Axis performance and MessageElement.equals()
> > > > > > > > >
> > > > > > > > > > hi,
> > > > > > > > > > this is exactly the second point i have mentioned at
> > > > > > > > > > http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > > >
> > > > > > > > > > I have also suggested a simple solution for this which will apply for
> > > > > > > > > > most of the situations.
> > > > > > > > > > this time i am attaching a patch for
> > > > > > > > > > src/org/apache/axis/message/NodeImpl.java and
> > > > > > > > > > src/org/apache/axis/message/MessageElement.java
> > > > > > > > > >
> > > > > > > > > > these two patches will solve the problem, most of the time. this will
> > > > > > > > > > surely boost performance.
> > > > > > > > > > you can have look at these patches to find out what i mean by most of the time.
> > > > > > > > > >
> > > > > > > > > > i will attach these patches in
> > > > > > > > > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > > > > > > > > >
> > > > > > > > > > thanks,
> > > > > > > > > > nishant
> > > > > > > > > >
> > > > > > > > > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > > > > > > > > Developers,
> > > > > > > > > > >
> > > > > > > > > > > I've been doing some performance profiling and I stumbled into
> > > > > > > > > > > MessageElement.equals(). Is there any reason why the equals method
> > > > > > > > > > > needs to compare strings? Can it not just compare the objects?
> > > > > > > > > > >
> > > > > > > > > > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > > > > > > > > > ArrayList of children. Many of the operations in NodeImpl use
> > > > > > > > > > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > > > > > > > > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > > > > > > > > > object, not an object that looks the same? While we're at it, shouldn't
> > > > > > > > > > > removeChild() return after finding the child? Currently, it continues
> > > > > > > > > > > to search for more children that equals() the child to remove. The DOM
> > > > > > > > > > > documents are not clear on this.
> > > > > > > > > > >
> > > > > > > > > > > Thank you.
> > > > > > > > > > >
> > > > > > > > > > > ~S
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: Axis performance and MessageElement.equals()
Posted by Nishant Kumar <ni...@itellix.com>.
hi dims,
I guess that Jongjin had suggested this change so may be he can review
this patch. I have the removed the try and the finally bocks, that's it.
attaching the patch again.
thanks,
nishant
On Fri, 2004-10-15 at 18:56, Davanum Srinivas wrote:
> Pls check the patch...it just removes a bunch of lines :(
>
> -- dims
>
>
> On 15 Oct 2004 18:45:50 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > you do release document builder to the cache but not when you get an
> > exception. when you get an exception you cannot be sure that the
> > document builder is in perfect state so better create a new one next
> > time. in the normal case (which will be far more than the exceptional
> > one) after creating the document object you can return the document
> > builder to its cache. i have done the same in the patch.
> >
> > thanks,
> >
> >
> > nishant
> >
> > On Fri, 2004-10-15 at 17:54, Davanum Srinivas wrote:
> > > Nishant,
> > >
> > > Am confused....What's the point of having a cache of DocumentBuilders
> > > if you don't release it back into the cache?
> > >
> > > -- dims
> > >
> > > On 15 Oct 2004 16:55:26 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > > > hi,
> > > > sorry, i meant we should NOT be releasing the documentbuilder in the
> > > > finally clause. we can just discard the builder if there is any
> > > > exception. kindly have a look at the attached patch. this suggestion is
> > > > based on the latest from the cvs.
> > > >
> > > >
> > > > bye for now,
> > > > nishant
> > > >
> > > > On Fri, 2004-10-15 at 15:40, Davanum Srinivas wrote:
> > > > > Nishant,
> > > > > check the latest CVS :)
> > > > >
> > > > > -- dims
> > > > >
> > > > >
> > > > > On 15 Oct 2004 10:13:47 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > > > > > hi Jongjin,
> > > > > > can you make a slight change to XMLUtils. I think we should be
> > > > > > releasing the documentbuilder in the finally clause. May be, we can just
> > > > > > discard the document builder if there is an exception. You can have a
> > > > > > look at the attached patch.
> > > > > >
> > > > > >
> > > > > > thanks,
> > > > > > nishant
> > > > > > On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> > > > > > > Jongjin,
> > > > > > >
> > > > > > > AXIS-1597 should be fixed now.
> > > > > > >
> > > > > > > -- dims
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi <gu...@hotmail.com> wrote:
> > > > > > > > Nishant,
> > > > > > > >
> > > > > > > > I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> > > > > > > > In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
> > > > > > > >
> > > > > > > > Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
> > > > > > > >
> > > > > > > > What do you think about that?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Jongjin/
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Nishant Kumar" <ni...@itellix.com>
> > > > > > > > To: <ax...@ws.apache.org>
> > > > > > > > Sent: Thursday, October 14, 2004 2:29 PM
> > > > > > > > Subject: Re: Axis performance and MessageElement.equals()
> > > > > > > >
> > > > > > > > > hi,
> > > > > > > > > this is exactly the second point i have mentioned at
> > > > > > > > > http://nishantkumar.com/notes/tuning/axis.html.
> > > > > > > > >
> > > > > > > > > I have also suggested a simple solution for this which will apply for
> > > > > > > > > most of the situations.
> > > > > > > > > this time i am attaching a patch for
> > > > > > > > > src/org/apache/axis/message/NodeImpl.java and
> > > > > > > > > src/org/apache/axis/message/MessageElement.java
> > > > > > > > >
> > > > > > > > > these two patches will solve the problem, most of the time. this will
> > > > > > > > > surely boost performance.
> > > > > > > > > you can have look at these patches to find out what i mean by most of the time.
> > > > > > > > >
> > > > > > > > > i will attach these patches in
> > > > > > > > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > > > > > > > >
> > > > > > > > > thanks,
> > > > > > > > > nishant
> > > > > > > > >
> > > > > > > > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > > > > > > > Developers,
> > > > > > > > > >
> > > > > > > > > > I've been doing some performance profiling and I stumbled into
> > > > > > > > > > MessageElement.equals(). Is there any reason why the equals method
> > > > > > > > > > needs to compare strings? Can it not just compare the objects?
> > > > > > > > > >
> > > > > > > > > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > > > > > > > > ArrayList of children. Many of the operations in NodeImpl use
> > > > > > > > > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > > > > > > > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > > > > > > > > object, not an object that looks the same? While we're at it, shouldn't
> > > > > > > > > > removeChild() return after finding the child? Currently, it continues
> > > > > > > > > > to search for more children that equals() the child to remove. The DOM
> > > > > > > > > > documents are not clear on this.
> > > > > > > > > >
> > > > > > > > > > Thank you.
> > > > > > > > > >
> > > > > > > > > > ~S
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Axis performance and MessageElement.equals()
Posted by Davanum Srinivas <da...@gmail.com>.
Nishant,
Am confused....What's the point of having a cache of DocumentBuilders
if you don't release it back into the cache?
-- dims
On 15 Oct 2004 16:55:26 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> hi,
> sorry, i meant we should NOT be releasing the documentbuilder in the
> finally clause. we can just discard the builder if there is any
> exception. kindly have a look at the attached patch. this suggestion is
> based on the latest from the cvs.
>
>
> bye for now,
> nishant
>
> On Fri, 2004-10-15 at 15:40, Davanum Srinivas wrote:
> > Nishant,
> > check the latest CVS :)
> >
> > -- dims
> >
> >
> > On 15 Oct 2004 10:13:47 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > > hi Jongjin,
> > > can you make a slight change to XMLUtils. I think we should be
> > > releasing the documentbuilder in the finally clause. May be, we can just
> > > discard the document builder if there is an exception. You can have a
> > > look at the attached patch.
> > >
> > >
> > > thanks,
> > > nishant
> > > On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> > > > Jongjin,
> > > >
> > > > AXIS-1597 should be fixed now.
> > > >
> > > > -- dims
> > > >
> > > >
> > > > On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi <gu...@hotmail.com> wrote:
> > > > > Nishant,
> > > > >
> > > > > I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> > > > > I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> > > > > In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
> > > > >
> > > > > Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
> > > > >
> > > > > What do you think about that?
> > > > >
> > > > >
> > > > >
> > > > > Jongjin/
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Nishant Kumar" <ni...@itellix.com>
> > > > > To: <ax...@ws.apache.org>
> > > > > Sent: Thursday, October 14, 2004 2:29 PM
> > > > > Subject: Re: Axis performance and MessageElement.equals()
> > > > >
> > > > > > hi,
> > > > > > this is exactly the second point i have mentioned at
> > > > > > http://nishantkumar.com/notes/tuning/axis.html.
> > > > > >
> > > > > > I have also suggested a simple solution for this which will apply for
> > > > > > most of the situations.
> > > > > > this time i am attaching a patch for
> > > > > > src/org/apache/axis/message/NodeImpl.java and
> > > > > > src/org/apache/axis/message/MessageElement.java
> > > > > >
> > > > > > these two patches will solve the problem, most of the time. this will
> > > > > > surely boost performance.
> > > > > > you can have look at these patches to find out what i mean by most of the time.
> > > > > >
> > > > > > i will attach these patches in
> > > > > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > > > > >
> > > > > > thanks,
> > > > > > nishant
> > > > > >
> > > > > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > > > > Developers,
> > > > > > >
> > > > > > > I've been doing some performance profiling and I stumbled into
> > > > > > > MessageElement.equals(). Is there any reason why the equals method
> > > > > > > needs to compare strings? Can it not just compare the objects?
> > > > > > >
> > > > > > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > > > > > ArrayList of children. Many of the operations in NodeImpl use
> > > > > > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > > > > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > > > > > object, not an object that looks the same? While we're at it, shouldn't
> > > > > > > removeChild() return after finding the child? Currently, it continues
> > > > > > > to search for more children that equals() the child to remove. The DOM
> > > > > > > documents are not clear on this.
> > > > > > >
> > > > > > > Thank you.
> > > > > > >
> > > > > > > ~S
> > > > > > >
> > > > > >
> > > >
> > >
> > >
> > >
> >
>
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis performance and MessageElement.equals()
Posted by Nishant Kumar <ni...@itellix.com>.
hi,
sorry, i meant we should NOT be releasing the documentbuilder in the
finally clause. we can just discard the builder if there is any
exception. kindly have a look at the attached patch. this suggestion is
based on the latest from the cvs.
bye for now,
nishant
On Fri, 2004-10-15 at 15:40, Davanum Srinivas wrote:
> Nishant,
> check the latest CVS :)
>
> -- dims
>
>
> On 15 Oct 2004 10:13:47 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> > hi Jongjin,
> > can you make a slight change to XMLUtils. I think we should be
> > releasing the documentbuilder in the finally clause. May be, we can just
> > discard the document builder if there is an exception. You can have a
> > look at the attached patch.
> >
> >
> > thanks,
> > nishant
> > On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> > > Jongjin,
> > >
> > > AXIS-1597 should be fixed now.
> > >
> > > -- dims
> > >
> > >
> > > On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi <gu...@hotmail.com> wrote:
> > > > Nishant,
> > > >
> > > > I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> > > > I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> > > > In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
> > > >
> > > > Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
> > > >
> > > > What do you think about that?
> > > >
> > > >
> > > >
> > > > Jongjin/
> > > >
> > > > ----- Original Message -----
> > > > From: "Nishant Kumar" <ni...@itellix.com>
> > > > To: <ax...@ws.apache.org>
> > > > Sent: Thursday, October 14, 2004 2:29 PM
> > > > Subject: Re: Axis performance and MessageElement.equals()
> > > >
> > > > > hi,
> > > > > this is exactly the second point i have mentioned at
> > > > > http://nishantkumar.com/notes/tuning/axis.html.
> > > > >
> > > > > I have also suggested a simple solution for this which will apply for
> > > > > most of the situations.
> > > > > this time i am attaching a patch for
> > > > > src/org/apache/axis/message/NodeImpl.java and
> > > > > src/org/apache/axis/message/MessageElement.java
> > > > >
> > > > > these two patches will solve the problem, most of the time. this will
> > > > > surely boost performance.
> > > > > you can have look at these patches to find out what i mean by most of the time.
> > > > >
> > > > > i will attach these patches in
> > > > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > > > >
> > > > > thanks,
> > > > > nishant
> > > > >
> > > > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > > > Developers,
> > > > > >
> > > > > > I've been doing some performance profiling and I stumbled into
> > > > > > MessageElement.equals(). Is there any reason why the equals method
> > > > > > needs to compare strings? Can it not just compare the objects?
> > > > > >
> > > > > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > > > > ArrayList of children. Many of the operations in NodeImpl use
> > > > > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > > > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > > > > object, not an object that looks the same? While we're at it, shouldn't
> > > > > > removeChild() return after finding the child? Currently, it continues
> > > > > > to search for more children that equals() the child to remove. The DOM
> > > > > > documents are not clear on this.
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > ~S
> > > > > >
> > > > >
> > >
> >
> >
> >
>
Re: Axis performance and MessageElement.equals()
Posted by Davanum Srinivas <da...@gmail.com>.
Nishant,
check the latest CVS :)
-- dims
On 15 Oct 2004 10:13:47 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> hi Jongjin,
> can you make a slight change to XMLUtils. I think we should be
> releasing the documentbuilder in the finally clause. May be, we can just
> discard the document builder if there is an exception. You can have a
> look at the attached patch.
>
>
> thanks,
> nishant
> On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> > Jongjin,
> >
> > AXIS-1597 should be fixed now.
> >
> > -- dims
> >
> >
> > On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi <gu...@hotmail.com> wrote:
> > > Nishant,
> > >
> > > I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> > > I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> > > In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
> > >
> > > Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
> > >
> > > What do you think about that?
> > >
> > >
> > >
> > > Jongjin/
> > >
> > > ----- Original Message -----
> > > From: "Nishant Kumar" <ni...@itellix.com>
> > > To: <ax...@ws.apache.org>
> > > Sent: Thursday, October 14, 2004 2:29 PM
> > > Subject: Re: Axis performance and MessageElement.equals()
> > >
> > > > hi,
> > > > this is exactly the second point i have mentioned at
> > > > http://nishantkumar.com/notes/tuning/axis.html.
> > > >
> > > > I have also suggested a simple solution for this which will apply for
> > > > most of the situations.
> > > > this time i am attaching a patch for
> > > > src/org/apache/axis/message/NodeImpl.java and
> > > > src/org/apache/axis/message/MessageElement.java
> > > >
> > > > these two patches will solve the problem, most of the time. this will
> > > > surely boost performance.
> > > > you can have look at these patches to find out what i mean by most of the time.
> > > >
> > > > i will attach these patches in
> > > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > > >
> > > > thanks,
> > > > nishant
> > > >
> > > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > > Developers,
> > > > >
> > > > > I've been doing some performance profiling and I stumbled into
> > > > > MessageElement.equals(). Is there any reason why the equals method
> > > > > needs to compare strings? Can it not just compare the objects?
> > > > >
> > > > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > > > ArrayList of children. Many of the operations in NodeImpl use
> > > > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > > > object, not an object that looks the same? While we're at it, shouldn't
> > > > > removeChild() return after finding the child? Currently, it continues
> > > > > to search for more children that equals() the child to remove. The DOM
> > > > > documents are not clear on this.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > ~S
> > > > >
> > > >
> >
>
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis performance and MessageElement.equals()
Posted by Nishant Kumar <ni...@itellix.com>.
hi Jongjin,
can you make a slight change to XMLUtils. I think we should be
releasing the documentbuilder in the finally clause. May be, we can just
discard the document builder if there is an exception. You can have a
look at the attached patch.
thanks,
nishant
On Thu, 2004-10-14 at 21:03, Davanum Srinivas wrote:
> Jongjin,
>
> AXIS-1597 should be fixed now.
>
> -- dims
>
>
> On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi <gu...@hotmail.com> wrote:
> > Nishant,
> >
> > I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> > I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> > In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
> >
> > Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
> >
> > What do you think about that?
> >
> >
> >
> > Jongjin/
> >
> > ----- Original Message -----
> > From: "Nishant Kumar" <ni...@itellix.com>
> > To: <ax...@ws.apache.org>
> > Sent: Thursday, October 14, 2004 2:29 PM
> > Subject: Re: Axis performance and MessageElement.equals()
> >
> > > hi,
> > > this is exactly the second point i have mentioned at
> > > http://nishantkumar.com/notes/tuning/axis.html.
> > >
> > > I have also suggested a simple solution for this which will apply for
> > > most of the situations.
> > > this time i am attaching a patch for
> > > src/org/apache/axis/message/NodeImpl.java and
> > > src/org/apache/axis/message/MessageElement.java
> > >
> > > these two patches will solve the problem, most of the time. this will
> > > surely boost performance.
> > > you can have look at these patches to find out what i mean by most of the time.
> > >
> > > i will attach these patches in
> > > http://issues.apache.org/jira/browse/AXIS-1497 too.
> > >
> > > thanks,
> > > nishant
> > >
> > > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > > Developers,
> > > >
> > > > I've been doing some performance profiling and I stumbled into
> > > > MessageElement.equals(). Is there any reason why the equals method
> > > > needs to compare strings? Can it not just compare the objects?
> > > >
> > > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > > ArrayList of children. Many of the operations in NodeImpl use
> > > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > > object, not an object that looks the same? While we're at it, shouldn't
> > > > removeChild() return after finding the child? Currently, it continues
> > > > to search for more children that equals() the child to remove. The DOM
> > > > documents are not clear on this.
> > > >
> > > > Thank you.
> > > >
> > > > ~S
> > > >
> > >
>
Re: Axis performance and MessageElement.equals()
Posted by Davanum Srinivas <da...@gmail.com>.
Jongjin,
AXIS-1597 should be fixed now.
-- dims
On Thu, 14 Oct 2004 16:23:24 +0900, Jongjin Choi <gu...@hotmail.com> wrote:
> Nishant,
>
> I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
>
> Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
>
> What do you think about that?
>
>
>
> Jongjin/
>
> ----- Original Message -----
> From: "Nishant Kumar" <ni...@itellix.com>
> To: <ax...@ws.apache.org>
> Sent: Thursday, October 14, 2004 2:29 PM
> Subject: Re: Axis performance and MessageElement.equals()
>
> > hi,
> > this is exactly the second point i have mentioned at
> > http://nishantkumar.com/notes/tuning/axis.html.
> >
> > I have also suggested a simple solution for this which will apply for
> > most of the situations.
> > this time i am attaching a patch for
> > src/org/apache/axis/message/NodeImpl.java and
> > src/org/apache/axis/message/MessageElement.java
> >
> > these two patches will solve the problem, most of the time. this will
> > surely boost performance.
> > you can have look at these patches to find out what i mean by most of the time.
> >
> > i will attach these patches in
> > http://issues.apache.org/jira/browse/AXIS-1497 too.
> >
> > thanks,
> > nishant
> >
> > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > Developers,
> > >
> > > I've been doing some performance profiling and I stumbled into
> > > MessageElement.equals(). Is there any reason why the equals method
> > > needs to compare strings? Can it not just compare the objects?
> > >
> > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > ArrayList of children. Many of the operations in NodeImpl use
> > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > object, not an object that looks the same? While we're at it, shouldn't
> > > removeChild() return after finding the child? Currently, it continues
> > > to search for more children that equals() the child to remove. The DOM
> > > documents are not clear on this.
> > >
> > > Thank you.
> > >
> > > ~S
> > >
> >
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis performance and MessageElement.equals()
Posted by Nishant Kumar <ni...@itellix.com>.
hi Jongjin,
firstly let me say that we agree that DocumentBuilder should be reused,
whether my way or your way or just any other acceptable way.
secondly why i proposed the thread local way is that i am not sure how
long is a document builder associated with a document it created. let me
explain this with a simple example.
say i create a document with a document builder (say db1). now if i
create a new Element using the document we just created. Will the
creation of this element have anything to do document builder or the
element is created by the document only. in axis i guess elements are
created by the document only.
simply stated if the document builder is NO WAY associated with the
document (in axis and all the other dom parsers) after the document has
been created then your way is the most appropriate, but if the document
keeps a reference to the document builder till the end of its life then
probably my way is better.
another benefit of thread local is that you don't need any
synchronization as an instance exists per thread. you don't have to
remember to return the document builder back to the pool in a finally
block.
any way finally i would like to insist again that document builder
should somehow be cached.
bye for now,
nishant
On Thu, 2004-10-14 at 12:53, Jongjin Choi wrote:
> Nishant,
>
> I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
> I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
> In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
>
> Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
>
> What do you think about that?
>
> Jongjin/
>
> ----- Original Message -----
> From: "Nishant Kumar" <ni...@itellix.com>
> To: <ax...@ws.apache.org>
> Sent: Thursday, October 14, 2004 2:29 PM
> Subject: Re: Axis performance and MessageElement.equals()
>
>
> > hi,
> > this is exactly the second point i have mentioned at
> > http://nishantkumar.com/notes/tuning/axis.html.
> >
> > I have also suggested a simple solution for this which will apply for
> > most of the situations.
> > this time i am attaching a patch for
> > src/org/apache/axis/message/NodeImpl.java and
> > src/org/apache/axis/message/MessageElement.java
> >
> > these two patches will solve the problem, most of the time. this will
> > surely boost performance.
> > you can have look at these patches to find out what i mean by most of the time.
> >
> > i will attach these patches in
> > http://issues.apache.org/jira/browse/AXIS-1497 too.
> >
> > thanks,
> > nishant
> >
> > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > Developers,
> > >
> > > I've been doing some performance profiling and I stumbled into
> > > MessageElement.equals(). Is there any reason why the equals method
> > > needs to compare strings? Can it not just compare the objects?
> > >
> > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > ArrayList of children. Many of the operations in NodeImpl use
> > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > object, not an object that looks the same? While we're at it, shouldn't
> > > removeChild() return after finding the child? Currently, it continues
> > > to search for more children that equals() the child to remove. The DOM
> > > documents are not clear on this.
> > >
> > > Thank you.
> > >
> > > ~S
> > >
> >
Re: Axis performance and MessageElement.equals()
Posted by Jongjin Choi <gu...@hotmail.com>.
Nishant,
I reviewed your note at http://nishantkumar.com/notes/tuning/axis.html.
I think the third point in your note, 'ThreadLocal for DocumentBuilder' is related to the jira issue AXIS-1597.
In AXIS-1597, I mentioned another way to reuse the DocumentBuilder.
Using this way, I think Axis can serve all threads with fewer number of DocumentBuilder compared to per-thread model.
What do you think about that?
Jongjin/
----- Original Message -----
From: "Nishant Kumar" <ni...@itellix.com>
To: <ax...@ws.apache.org>
Sent: Thursday, October 14, 2004 2:29 PM
Subject: Re: Axis performance and MessageElement.equals()
> hi,
> this is exactly the second point i have mentioned at
> http://nishantkumar.com/notes/tuning/axis.html.
>
> I have also suggested a simple solution for this which will apply for
> most of the situations.
> this time i am attaching a patch for
> src/org/apache/axis/message/NodeImpl.java and
> src/org/apache/axis/message/MessageElement.java
>
> these two patches will solve the problem, most of the time. this will
> surely boost performance.
> you can have look at these patches to find out what i mean by most of the time.
>
> i will attach these patches in
> http://issues.apache.org/jira/browse/AXIS-1497 too.
>
> thanks,
> nishant
>
> On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > Developers,
> >
> > I've been doing some performance profiling and I stumbled into
> > MessageElement.equals(). Is there any reason why the equals method
> > needs to compare strings? Can it not just compare the objects?
> >
> > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > ArrayList of children. Many of the operations in NodeImpl use
> > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > removeChild(), insertBefore(), etc... should be looking for a specific
> > object, not an object that looks the same? While we're at it, shouldn't
> > removeChild() return after finding the child? Currently, it continues
> > to search for more children that equals() the child to remove. The DOM
> > documents are not clear on this.
> >
> > Thank you.
> >
> > ~S
> >
>
Re: Axis performance and MessageElement.equals()
Posted by Davanum Srinivas <da...@gmail.com>.
Nishant,
Keep 'em coming....will be checking in the 2 diffs in a few mins. Yes,
please add the diffs to AXIS-1497 AND please use "diff -u" to make the
diff more readable.
-- dims
On 14 Oct 2004 11:34:46 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> some how NodeImpl.diff got corrupted. here is the correct file.
>
> thanks,
> nishant
>
>
>
> On Thu, 2004-10-14 at 10:59, Nishant Kumar wrote:
> > hi,
> > this is exactly the second point i have mentioned at
> > http://nishantkumar.com/notes/tuning/axis.html.
> >
> > I have also suggested a simple solution for this which will apply for
> > most of the situations.
> > this time i am attaching a patch for
> > src/org/apache/axis/message/NodeImpl.java and
> > src/org/apache/axis/message/MessageElement.java
> >
> > these two patches will solve the problem, most of the time. this will
> > surely boost performance.
> > you can have look at these patches to find out what i mean by most of the time.
> >
> > i will attach these patches in
> > http://issues.apache.org/jira/browse/AXIS-1497 too.
> >
> > thanks,
> > nishant
> >
> > On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > > Developers,
> > >
> > > I've been doing some performance profiling and I stumbled into
> > > MessageElement.equals(). Is there any reason why the equals method
> > > needs to compare strings? Can it not just compare the objects?
> > >
> > > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > > ArrayList of children. Many of the operations in NodeImpl use
> > > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > > removeChild(), insertBefore(), etc... should be looking for a specific
> > > object, not an object that looks the same? While we're at it, shouldn't
> > > removeChild() return after finding the child? Currently, it continues
> > > to search for more children that equals() the child to remove. The DOM
> > > documents are not clear on this.
> > >
> > > Thank you.
> > >
> > > ~S
> > >
>
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis performance and MessageElement.equals()
Posted by Nishant Kumar <ni...@itellix.com>.
some how NodeImpl.diff got corrupted. here is the correct file.
thanks,
nishant
On Thu, 2004-10-14 at 10:59, Nishant Kumar wrote:
> hi,
> this is exactly the second point i have mentioned at
> http://nishantkumar.com/notes/tuning/axis.html.
>
> I have also suggested a simple solution for this which will apply for
> most of the situations.
> this time i am attaching a patch for
> src/org/apache/axis/message/NodeImpl.java and
> src/org/apache/axis/message/MessageElement.java
>
> these two patches will solve the problem, most of the time. this will
> surely boost performance.
> you can have look at these patches to find out what i mean by most of the time.
>
> i will attach these patches in
> http://issues.apache.org/jira/browse/AXIS-1497 too.
>
> thanks,
> nishant
>
> On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> > Developers,
> >
> > I've been doing some performance profiling and I stumbled into
> > MessageElement.equals(). Is there any reason why the equals method
> > needs to compare strings? Can it not just compare the objects?
> >
> > The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> > ArrayList of children. Many of the operations in NodeImpl use
> > ArrayList.indexOf() which calls equals(). Isn't it the case that
> > removeChild(), insertBefore(), etc... should be looking for a specific
> > object, not an object that looks the same? While we're at it, shouldn't
> > removeChild() return after finding the child? Currently, it continues
> > to search for more children that equals() the child to remove. The DOM
> > documents are not clear on this.
> >
> > Thank you.
> >
> > ~S
> >
Re: Axis performance and MessageElement.equals()
Posted by Nishant Kumar <ni...@itellix.com>.
hi,
this is exactly the second point i have mentioned at
http://nishantkumar.com/notes/tuning/axis.html.
I have also suggested a simple solution for this which will apply for
most of the situations.
this time i am attaching a patch for
src/org/apache/axis/message/NodeImpl.java and
src/org/apache/axis/message/MessageElement.java
these two patches will solve the problem, most of the time. this will
surely boost performance.
you can have look at these patches to find out what i mean by most of the time.
i will attach these patches in
http://issues.apache.org/jira/browse/AXIS-1497 too.
thanks,
nishant
On Thu, 2004-10-14 at 03:21, Steve Green wrote:
> Developers,
>
> I've been doing some performance profiling and I stumbled into
> MessageElement.equals(). Is there any reason why the equals method
> needs to compare strings? Can it not just compare the objects?
>
> The reason I ask is because of because of NodeImpl. NodeImpl keeps an
> ArrayList of children. Many of the operations in NodeImpl use
> ArrayList.indexOf() which calls equals(). Isn't it the case that
> removeChild(), insertBefore(), etc... should be looking for a specific
> object, not an object that looks the same? While we're at it, shouldn't
> removeChild() return after finding the child? Currently, it continues
> to search for more children that equals() the child to remove. The DOM
> documents are not clear on this.
>
> Thank you.
>
> ~S
>