[jdom-interest] JAXP performance problems

[Klotz, Leigh]

You're quite right that people should reuse factories and even builders
if possible, but unfortunately setting the system property does not
help.
Turn on -Djaxp.debug and see how many times it prints out the
classloader.
That's the same number of times it will call
String.valueOf(classloader).
With Tomcat in place (4.1.x, 5.5), the call to classloader.toString() is
incredibly expensive.
So even setting the system property doesn't help in JDK 1.5.0
implementation of JAXP because DocumentBuilderFactory and
SAXParserFactory still invoke javax.xml.parsers.FactoryFinder, which you
can see through -Djaxp.debug without even glancing at the Sun source
code.

So the bug I fild with Sun is to fix this needless calculation of
classloader.toString().

And I think that repeating the advice to re-use factories is valuable.

Leigh.


-----Original Message-----
From: jdom-interest-bounces at jdom.org
[mailto:jdom-interest-bounces at jdom.org] On Behalf Of Tatu Saloranta
Sent: Friday, September 15, 2006 4:03 PM
To: jdom-interest at jdom.org
Subject: Re: [jdom-interest] JAXP performance problems

--- "Klotz, Leigh" <Leigh.Klotz at xerox.com> wrote:

> I've recently found two JAXP performance problems. 
> I've filed a bug
> with Sun on them.

I was under impression that these were somewhat
well-known (and quite severe) problems. It has been
discussed on various mailing lists earlier (SAX, StAX
at least). ;-/

Unfortunately I think there is little that can be done
to fix the process of factory discovery, as specified:
changes that would improve performance would by
necessity have to change behavior. This because the
expensive part (that of discovering services files
using class loader) is inherently dynamic: and caching
based on class-loader would be tricky.
So I wouldn't count on Sun fixing it any time soon --
it's not easy to fix.

So how do I know this? I investigated the problem in
relation to Stax implementations... it's quite
expensive to do factory.newInstance() call, anywhere
from 5 milliseconds up (for some web app containers
probably much higher than that). While it's possible
to cache results of the first 2 methods (system prop,
jaxp.properties file read), those are not the main
problem... and caching last one would have to be on
per-classloader basis, without having hard reference
to class loader. Perhaps if class loader object
supported caching of discovery mechanism, this could
be done.

This is something users have to be aware of:
preferably by reusing factories, or if not, using a
workaround:

(a) Setting the system property that is used to find
the factory class. Accessing this is relatively cheap.
(b) Using the actual implementation factory directly,
using a app-specific property: while this removes the
complete implementation independency, it should be
easy to wire things using Springs or such.

-+ Tatu +-



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com