&gt; **NOTE: If you experience this issue as well, please upvote it on Apache JIRA:**
&gt;
&gt; https://issues.apache.org/jira/browse/XALANJ-2540


I have come to an astonishing conclusion that this:

    Element e = (Element) document.getElementsByTagName(&quot;SomeElementName&quot;).item(0);
    String result = ((Element) e).getTextContent();

Seems to be an incredible 100x faster than this:

    // Accounts for 30%, can be cached
    XPathFactory factory = XPathFactory.newInstance();

    // Negligible
    XPath xpath = factory.newXPath();

    // Negligible
    XPathExpression expression = xpath.compile(&quot;//SomeElementName&quot;);

    // Accounts for 70%
    String result = (String) expression.evaluate(document, XPathConstants.STRING);

I&#39;m using the JVM&#39;s default implementation of JAXP:

    org.apache.xpath.jaxp.XPathFactoryImpl
    org.apache.xpath.jaxp.XPathImpl

I&#39;m really confused, because it&#39;s easy to see how JAXP could optimise the above XPath query to actually execute a simple `getElementsByTagName()` instead. But it doesn&#39;t seem to do that. This problem is limited to around 5-6 frequently used XPath calls, that are abstracted and hidden by an API. Those queries involve simple paths (e.g. `/a/b/c`, no variables, conditions) against an always available DOM Document only. So, if an optimisation can be done, it will be quite easy to achieve.

My question: Is XPath&#39;s slowness an accepted fact, or am I overlooking something? Is there a better (faster) implementation? Or should I just avoid XPath altogether, for simple queries?

All Jaxp Solutions on Gang of Coders

Total of 1 Jaxp Solutions

Java XPath (Apache JAXP implementation) performance