Java XPath(Apache JAXP实现)性能

Question

注意:如果您遇到此问题,请在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抽象和隐藏.这些查询涉及/a/b/c仅针对始终可用的DOM文档的简单路径(例如,无变量,条件).因此,如果可以进行优化,则很容易实现.

我的问题:XPath的缓慢是一个公认的事实,还是我忽略了什么？是否有更好(更快)的实施？或者我应该完全避免XPath,简单查询？

Answer 1

我已经调试并分析了我的测试用例和Xalan/JAXP.我设法找出了最大的主要问题

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

可以看出,10k测试XPath评估中的每一个都导致类加载器尝试DTMManager在某种默认配置中查找实例.此配置不会加载到内存中,但每次都会访问.此外,这种访问似乎受到ObjectFactory.class自身锁定的保护.当访问失败时(默认情况下),则从xalan.jar文件加载配置

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

配置文件.每次!:

幸运的是,可以通过指定如下的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文件的10k连续XPath评估的性能改进概述(测量为System.nanoTime():

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   |

请注意,基准测试非常原始.很可能你自己的基准测试表明撒克逊人的表现优于xalan

我已将此作为一个错误提交给Apache的Xalan人员:

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

Answer 2

不是解决方案,而是指向主要问题的指针:评估与任意节点相关的xpath的过程中最慢的部分是DTM管理器找到节点句柄所花费的时间:

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%

如果有问题的节点位于Document的末尾,则它可以最终遍历整个树以查找相关节点,以查找每个查询.

这解释了为什么孤立目标节点的黑客工作.这里应该是缓存这些查询的方式,但在这一点上我看不出.