Re: Getting optimal performance for CachedXpathApi searches and DOM parsing

For point #1 below, I have dug around a bit more and the code is relatively easy to understand (CachedXpathApi).  I can basically mimic the behaviour of the CachedXpathApi myself and this allows me to precompile my Xpath and also I can just create XpathContext(false) and call reset() on it, just like the code does.  This will work around my problem for #1.

CachedXpathApi()
{
  xpathSupport = new CachedXpathApi(false);
}

public XObject eval(Node contextNode, String str, Node namespaceNode)
        throws TransformerException
    {
        PrefixResolverDefault prefixResolver = new PrefixResolverDefault(((Node) (namespaceNode.getNodeType() != 9 ? namespaceNode : ((Node) (((Document)namespaceNode).getDocumentElement())))));
        XPath xpath = new XPath(str, null, prefixResolver, 0, null);
        int ctxtNode = xpathSupport.getDTMHandleFromNode(contextNode);
        return xpath.execute(xpathSupport, ctxtNode, prefixResolver);
    }


--- On Wed, 9/30/09, Sandeep Takhar <[email protected]> wrote:

> From: Sandeep Takhar <[email protected]>
> Subject: Getting optimal performance for CachedXpathApi searches and DOM parsing
> To: [email protected]
> Received: Wednesday, September 30, 2009, 9:24 PM
> Hi. 
> 
> I am new to the list and sorry if I get something
> wrong.  I searched the existing archives, but could not
> find the answer I am looking for.  Thanks for any help
> you have.  
> 
> We are seeing some small performance issues in our
> production environment.  I am busy seeing if I can
> reproduce them.  My questions are regarding these
> issues and possibly working around them.
> 
> 1. CachedXpathApi is working well for us. I do see that the
> constructor is expensive.  I read on some IBM
> documentation that if you don't reuse parsers..the
> constructor is expensive because it tries to find a factory
> via jar file location (looping through the classpath). 
> In fact I see this happening when I look at the thread
> dump.  I see all the documentation and comments that
> indicate if you change a source document, then you need a
> new CachedXpathApi.  I see two things that I am not
> sure may work.
> 
> a) cachedXpathApi.getXpathContext().reset().  Can I
> call this instead of creating a new CachedXpathApi and then
> using the cachedXpathApi object to search new
> document?  I will still make the cachedXpathApi only
> execute in a single thread, but I don't want to call the
> constructor.
> b)There is also a constructor which takes another
> CachedXpathApi(CachedXPathApi cachedXpathApi).  Is this
> of some use?
> c) Can I use compiled xpath expressions and achieve a
> similar effect as the CachedXpathApi somehow...where I don't
> have to construct the CachedXpathApi()?  Does someone
> have a quick sample?
> 
> 2. We are using the apache DOM parser.  Basically the
> DOMParser is the default apache one (version 2.7.0). 
> Currently we create the Builder from the factory and then
> call parse. 
> DocumentBuilderFactory.newDocumentBuilder()....I cannot
> remember exactly the syntax.  We can certainly not have
> to create the DocumentBuilder each time and I am suggesting
> this as a fix.  What I see happen is that there is some
> minor performance issues that happen in production in the
> parse method.  I don't have the execution thread handy,
> but it is always spending time on
> DocumentScanner$DTDDispatcher.dispatch method (may not be
> exact syntax)  Looks like all methods for the
> declaration handler.  I have to double check that, but
> the methods are named like the sax declaration handler...but
> we are not using SAX.  We have an entityId as the
> second line in the xml file that points to a DTD that only
> has a single line in the DTD file.  I've tried to
> understand the code, but haven't
>  been able to figure it out
> 
> a) Will I stop seeing DTDDispatcher time taken in the
> threads if I remove the entity line in the source xml (no
> reference to a DTD)?
> b) Is what I'm seeing completely normal?
> c) can I set a property that will turn off the
> DTDDispatcher.dispatch method from being called?
> 
> 
> 
> Here are the methods I see that are spending time and
> things like string.intern().  Maybe it is completely
> normal, but it doesn't explain why it is slower in
> production...except that production load may be causing
> it...and that would be fine.
> 
> public void elementDecl(String name, String model)
>    throws SAXException;
>   public void attributeDecl(String elementName, 
>    String attributeName, String type, String
> mode, 
>    String defaultValue) throws
> SAXException;
>   public void internalEntityDecl(String name, String
> value) 
>    throws SAXException;
>   public void externalEntityDecl(String name, String
> publicID, 
>    String systemID) throws SAXException;
> 
> 
> 
> 
> 
>      
> __________________________________________________________________
> Yahoo! Canada Toolbar: Search from anywhere on the web, and
> bookmark your favourite sites. Download it now
> http://ca.toolbar.yahoo.com.
> 


      __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
http://ca.toolbar.yahoo.com.