Java XPath（Apache JAXP实现）的性能

注意：如果您也遇到此问题，请在Apache JIRA上加注：

https://issues.apache.org/jira/browse/XALANJ-2540

我得出了一个惊人的结论：

Element e = (Element) document.getElementsByTagName("SomeElementName").item(0); String result = ((Element) e).getTextContent(); 

似乎是一个令人难以置信的100倍比这更快：

 // Accounts for 30%, can be cached XPathFactory factory = XPathFactory.newInstance(); // Negligible XPath xpath = factory.newXPath(); // Negligible XPathExpression expression = xpath.compile("//SomeElementName"); // Accounts for 70% String result = (String) expression.evaluate(document, XPathConstants.STRING); 

我正在使用JVM的JAXP默认实现：

 org.apache.xpath.jaxp.XPathFactoryImpl org.apache.xpath.jaxp.XPathImpl 

我很困惑，因为很容易看出JAXP如何优化上述XPath查询来实际执行一个简单的getElementsByTagName() 。 但似乎并没有这样做。 这个问题被限制在5-6个经常使用的XPath调用中，这些调用被API抽象和隐藏。 这些查询只涉及简单的path（例如， /a/b/c ，无variables，条件），而不仅仅是一个始终可用的DOM文档。 所以，如果可以做一个优化，这将是很容易实现的。

我的问题：XPath的缓慢是一个公认的事实，还是我忽略了一些东西？ 有更好的（更快）的实施？ 或者我应该完全避免XPath，为简单的查询？

Answer 1

我已经debugging和概述了我的testing用例和Xalan / JAXP。 我设法确定了这个重大的问题

 org.apache.xml.dtm.ObjectFactory.lookUpFactoryClassName() 

可以看出，10ktestingXPath评估中的每一个都导致类加载器尝试以某种默认configuration查找DTMManager实例。 这个configuration没有加载到内存中，而是每次访问。 而且，这个访问似乎被ObjectFactory.class本身的一个锁保护着。 当访问失败时（默认），则configuration从xalan.jar文件中加载

 META-INF/service/org.apache.xml.dtm.DTMManager 

configuration文件。 每次！ ：

幸运的是，这种行为可以通过指定一个像这样的JVM参数来覆盖：

 -Dorg.apache.xml.dtm.DTMManager= org.apache.xml.dtm.ref.DTMManagerDefault 

要么

 -Dcom.sun.org.apache.xml.internal.dtm.DTMManager= com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault 

上面的工作，因为这将允许绕过lookUpFactoryClassName()昂贵的工作，如果工厂类的名称是默认的：

 // Code from com.sun.org.apache.xml.internal.dtm.ObjectFactory static String lookUpFactoryClassName(String factoryId, String propertiesFilename, String fallbackClassName) { SecuritySupport ss = SecuritySupport.getInstance(); try { String systemProp = ss.getSystemProperty(factoryId); if (systemProp != null) { // Return early from the method return systemProp; } } catch (SecurityException se) { } // [...] "Heavy" operations later 

所以//SomeNodeName针对一个90k XML文件（用System.nanoTime()测量System.nanoTime()的//SomeNodeName 10k个连续XPath评估的性能改进概述：

 measured library : Xalan 2.7.0 | Xalan 2.7.1 | Saxon-HE 9.3 | jaxen 1.1.3 -------------------------------------------------------------------------------- without optimisation : 10400ms | 4717ms | | 25500ms reusing XPathFactory : 5995ms | 2829ms | | reusing XPath : 5900ms | 2890ms | | reusing XPathExpression : 5800ms | 2915ms | 16000ms | 25000ms adding the JVM param : 1163ms | 761ms | n/a | 

注意基准是非常原始的。 你自己的基准很可能会显示出撒克逊胜过西兰

我已经把这个作为一个bug提交给了Apache的Xalan人：

https://issues.apache.org/jira/browse/XALANJ-2540

Answer 2

不是一个解决scheme，而是一个指向主要问题的指针：评估与任意节点相关的xpath的最慢部分是DTMpipe理器查找节点句柄所花费的时间：

http://javasourcecode.org/html/open-source/jdk/jdk-6u23/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTM.html#getHandleOfNode%28org.w3c.dom。节点29％;

如果所讨论的节点在文档的末尾，那么可以最终遍历整个树来查找所讨论的节点，用于每个查询。

这就解释了为什么黑客孤立出来的目标节点的作品。 应该有一种方法来caching这些查找，但在这一点上，我不明白如何。

Answer 3

为了回答你的问题，vtd-xml的速度比Jaxen或Xalan快（我平均说10倍，而60x已经被报道了…