[XALANJ-917] Performance Issue - CachedXPathAPI

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.4
• Component/s: XPath
• Environment: Operating System: All; Platform: All
• Bugzilla Id: 7294
• Assignee: Unassigned
• Reporter: Aaron Hughes
• Created: 21/Mar/02 03:08
• Updated: 11/Aug/05 13:39

Description

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