[jdom-interest] JAXP performance problems

[Tatu Saloranta]

--- "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