56

注意：如果您也遇到此问题，请在 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 来进行简单的查询？

4

3 回答 3

63

我已经调试并分析了我的测试用例和 Xalan/JAXP。我设法确定了

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

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

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

配置文件。每次！：

JProfiler 分析结果

幸运的是，可以通过指定这样的 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

于 2011-06-14T09:45:02.743 回答
6

不是解决方案，而是指向主要问题的指针：评估与任意节点相关的 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

如果有问题的节点位于文档的末尾，它最终可以遍历整个树以找到有问题的节点，对于每个查询。

这解释了为什么孤立目标节点的黑客行为有效。应该有一种方法来缓存这些查找，但在这一点上我不知道如何。

于 2011-12-23T07:32:05.730 回答
0

要回答你的问题，vtd-xml 比 Jaxen 或 Xalan 快得多）（我会说平均 10 倍，据报道有 60 倍......

于 2013-07-29T08:14:49.163 回答