Bug #3289
closed
Performance bottleneck in SystemFunctionLibrary
Fixed in Maintenance Release:
Description
When an application attempts to create many new paths in parallel they get blocked by SystemFunctionLibrary.getSystemFunctionLibrary which is synchronized. Even after the cache in "THE_INSTANCES" is built threads creating new paths still get bottlenecked by the synchronization.
One option would be to remove the synchronization and use a concurrent map to ensure all callers use the same objects. Attached is such a potential change to SystemFunctionLibrary
Files
Example of call hierarchy that is hitting the synchronized block.
net.sf.saxon.functions.SystemFunctionLibrary.getSystemFunctionLibrary(int, Configuration)
net.sf.saxon.sxpath.AbstractStaticContext.setDefaultFunctionLibrary()
net.sf.saxon.xpath.JAXPXPathStaticContext.(Configuration)
net.sf.saxon.xpath.XPathEvaluator.(Configuration)
net.sf.saxon.xpath.XPathFactoryImpl.newXPath()
The SystemFunctionLibrary has been completely redesigned for 9.8 and I think this particular contention spot should disappear. But we should probably look top-down at the performance of a workload that's doing a large number of XPath compile-and-go operations.
I suspect you might get better throughput if you run at lower concurrency?
And I wonder if you would get better performance if you used the s9api interface rather than JAXP? Unlike the JAXP XPath object, the s9api XPathCompiler is thread-safe once configured, and I suspect it has a significantly lower initialisation cost.
(Actually, Saxon's implementation of the JAXP XPath interface is thread-safe once configured, even though the API says it doesn't have to be.)
Thanks! I'll have to try the next release of 9.8 and I'll experiment with the s9api.
- Category set to Performance
- Status changed from New to Closed
- Assignee set to Michael Kay
I'm closing this with no action. Feel free to reopen if new evidence comes to light.
Please register to edit this issue
Also available in: Atom
PDF
.