DO NOT REPLY [Bug 7294] New: - Performance Issue - CachedXPathAPI

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7294>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7294

Performance Issue - CachedXPathAPI

           Summary: Performance Issue - CachedXPathAPI
           Product: XalanJ2
           Version: 2.3
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: org.apache.xpath
        AssignedTo: xalan-dev@xml.apache.org
        ReportedBy: ahughes@tutsys.com


The current implementation of the CachedXPathAPI object creates XPath object 
during the eval(), and provides a "null" ErrorHandling interface. 

// Create the XPath object.
XPath xpath = new XPath(str, null, prefixResolver, XPath.SELECT, null);
                                                                 ^^^^
This causes the XPath constructor to create a DefaultErrorHandler. The 
DefaultErrorHandler creates a new PrintWriter around System.err. When there are 
lots of eval() method calls being made using the CachedXPathAPI object, there 
are lots of un-needed DefaultErrorHandlers being created. Through profiling, I 
determined that 30% of the CPU utilization associated with calls to eval() were 
being attributed to creating the DefaultErrorHandlers.

PROPOSAL:
I propose that you add functionality to either alter the constructor of the 
CachedXPathAPI object to accept an ErrorHandler:

public CachedXPathAPI(ErrorHandler); // and variations

or add proper accessor methods to the CachedXPathAPI object:

public ErrorHandler getErrorHandler();
public void setErrorHandler(ErrorHandler errorHandler);

Thanks,
Aaron