axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nishant Kumar <nishant.ku...@itellix.com>
Subject Re: Axis performance and MessageElement.equals()
Date Thu, 14 Oct 2004 08:11:47 GMT
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" <nishant.kumar@itellix.com>
> To: <axis-dev@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
> > > 
> > 


Mime
View raw message