Performances de Java XPath (implémentation Apache JAXP)

Question

REMARQUE : si vous rencontrez également ce problème, merci de le soumettre à la validation sur Apache JIRA :

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

J'en suis arrivé à la conclusion étonnante que ceci :

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

Il semble être incroyablement 100x plus rapide que ça :

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

J'utilise l'implémentation par défaut de JAXP de la JVM :

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

Je suis vraiment confus, parce qu'il est facile de voir comment JAXP pourrait optimiser la requête XPath ci-dessus pour exécuter en fait un simple getElementsByTagName() à la place. Mais il ne semble pas le faire. Ce problème est limité à environ 5-6 appels XPath fréquemment utilisés, qui sont abstraits et cachés par une API. Ces requêtes impliquent des chemins simples (par ex. /a/b/c sans variables, ni conditions) par rapport à un document DOM toujours disponible uniquement. Donc, si une optimisation peut être faite, elle sera assez facile à réaliser.

Ma question : La lenteur de XPath est-elle un fait reconnu, ou est-ce que je néglige quelque chose ? Existe-t-il une meilleure implémentation (plus rapide) ? Ou devrais-je simplement éviter XPath pour les requêtes simples ?

Answer 1

J'ai débogué et profilé mon cas de test et Xalan/JAXP en général. J'ai réussi à identifier le gros problème majeur dans

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

On peut voir que chacune des 10 000 évaluations XPath du test a conduit le chargeur de classes à essayer de rechercher le fichier DTMManager dans une sorte de configuration par défaut. Cette configuration n'est pas chargée en mémoire, mais on y accède à chaque fois. De plus, cet accès semble être protégé par un verrou sur l'objet ObjectFactory.class même. Lorsque l'accès échoue (par défaut), la configuration est alors chargée à partir du fichier xalan.jar du fichier

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

le fichier de configuration. A chaque fois ! :

Heureusement, ce comportement peut être modifié en spécifiant un paramètre JVM comme ceci :

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

o

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

Ce qui précède fonctionne, car cela permettra de contourner le travail coûteux en lookUpFactoryClassName() si le nom de la classe d'usine est de toute façon la valeur par défaut :

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

Voici donc un aperçu de l'amélioration des performances pour 10 000 évaluations XPath consécutives de //SomeNodeName contre un fichier XML de 90k (mesuré avec 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   |

notez que le benchmark était très primitif. il se peut que votre propre benchmark montre que saxon surpasse xalan

J'ai signalé ce problème aux responsables de Xalan chez Apache :

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

Answer 2

Ce n'est pas une solution, mais une indication du problème principal : Le site le plus lent Une partie du processus d'évaluation d'un xpath par rapport à un nœud arbitraire est le temps que prend le gestionnaire de MNT pour trouver le handle du nœud :

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

Si le nœud en question se trouve à la fin du document, il peut finir par parcourir l'arbre entier pour trouver le nœud en question, pour chaque requête.

Cela explique pourquoi le hack pour rendre orphelin le noeud cible fonctionne. Il y a devrait être un moyen de mettre en cache ces recherches, mais pour l'instant je ne vois pas comment.

Answer 3

Pour répondre à votre question, vtd-xml est bien plus rapide que Jaxen ou Xalan) (je dirais en moyenne 10x, et 60x a été rapporté...