Java XPathApache JAXP实现性能

如何解决Java XPathApache 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抽象和隐藏。这些查询仅针对始终可用的DOM文档涉及简单路径（例如/a/b/c，没有变量，条件）。因此，如果可以进行优化，将很容易实现。我的问题：XPath的速度慢是公认的事实，还是我忽略了某些事情？是否有更好（更快）的实现？或者对于简单的查询，我应该完全避免使用XPath吗？

解决方法

通常，我已经调试并分析了我的测试用例和Xalan / JAXP。我设法找出了主要的重大问题

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

可以看出，每10k测试XPath评估中的每一个都导致类加载器尝试以某种默认配置查找“ 6”实例。此配置不会加载到内存中，但每次都会访问。此外，这种访问似乎受到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

上面的方法可以正常工作，因为如果工厂类名仍然是默认值，这将绕过ѭ12中的昂贵工作：

// 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

因此，这是针对90k XML文件（以System.nanoTime()度量）对1014进行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   |

请注意，基准是非常原始的基准。您自己的基准测试很可能表明撒克逊胜过xalan 我已将其作为错误提交给Apache的Xalan员工： https://issues.apache.org/jira/browse/XALANJ-2540 , 不是解决方案，而是主要问题的指针：评估与任意节点有关的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 如果有问题的节点位于文档的末尾，那么对于每个查询，它最终可能会遍历整个树以找到有问题的节点。这解释了为什么孤立目标节点的黑客工作的原因。应该有一种方法可以缓存这些查询，但是目前还看不到。 , 为了回答您的问题，vtd-xml比Jaxen或Xalan快得多（我会说平均据报道是10倍和60倍...

Java XPathApache JAXP实现性能

如何解决Java XPathApache JAXP实现性能

解决方法

相关推荐