Q: parsers and performance

[sh...@csc.com]

I have a question about how to improve the performance of my application and
also to get a "sanity check" from others using Xalan to see if what we're doing
is reasonable.

We are using Xalan-J 1.0 in a web application using IBM's JDK 1.1.8 running on
Windows NT Server 4.0 SP6.  We are doing a two-phase transformation, where the
XML from an application transaction is transformed (via a page-specific XSL)
into another document that is finally processed with a single master XSL
stylesheet into HTML.  This is done in a way similar to the Xalan sample code
called "Pipe".

When I call XSLTProcessorFactory.getProcessor(), I instantiate a new
XercesLiaison rather than using the default DTMLiaison.  This was done to work
around exceptions using DTMLiaison (not implemented: DeferredDocumentImpl, or
some such- as I remember).  We are using pre-processed stylesheets (caching the
StylesheetRoot object returned from processStylesheet) and calling setStylesheet
on the processors.

We have a requirement to parse the 1st phase XML and handle PIs.  To do that, I
extended org.apache.xerces.parsers.DOMParser and handled the PIs as required.
After this parse, I am left with a DOM node.  I assumed (possibly incorrectly)
that it would be more efficient to pass the DOM node to the processor as an
XSLTInputSource rather than letting it re-parse the source XML.

I have done some profiling of our application and have found that 98% of the
sample was spent transforming XML.  Drilling down further into the CPU profile
shows almost all of that time was spent in XercesLiaison.parse.  Performance is
not good, but I suppose that is to be expected with two phases of XSL(T).

Does all this sound reasonable?  Are there any performance suggestions?

Thanks in advance-
-Steve

-----------------------------------------------------------------------------------------------------------
Steve Horne
Systems Architect
Computer Sciences Corp.
Healthcare Group

Re: parsers and performance

[Jon Smirl <jo...@mediaone.net>]

I have exactly the same architecture and performance problem. Except I'm
using the C versions.

The call to XercesLiaison.parse() is misleading. The way SAX works parse()
generates all of the callbacks like startdocument(), statelement(), etc. So
by measuring parse() you would be measuring your entire transform time. You
need a break down of what parse is calling.

Jon Smirl
jonsmirl@mediaone.net