Problème de perf TinyXPath

Bonjour,

j'utilise TinyXPath pour lire des fichiers XML en faisant des requêtes XPath et j'ai des soucis de performance.

Mon fichier XML fait 1,4 Mo, et son ouverture est quasi instantanée. Par contre, mes fonctions de lecture qui vont enregistrer les données via des requêtes XPath sont très longues. Il me faut à peu près 45 minutes sur une bonne machine pour tout enregistrer.

Est-ce normal?
Sinon, comment puis-je gagner en performances?
Dois-je changer de librairie, et si oui, laquelle me conseillez vous (avec interface XPath)?

Merci pour votre aide.

Hello,
Je connais pas cette librairie, mais faut peut être déjà commencer par voir si les XPATH sont optimum ou non.
Et tu parles d'enregistrement dans les 45 minutes, ce qui est hors XPATH.

Peut être que tu peux déconnecter la lecture de l'enregistrement pour tester indépendamment les perf des 2.

Et oui, 45 minutes c'est bcp bcp trop:aie:.

En fait, l'ouverture du fichier XML et la création de l'arbre DOM correspondant sont quasiment instantanés pour le fichier de 1,4 Mo.

Ce qui prend du temps c'est de faire une requête XPath pour accéder à un attribut. Par exemple quand je veux accéder à 10 attributs d'une même balise, je fais 10 requêtes XPath du style /Balise1/Balise2/Balise3[indice]/@monAttribut. Du coup, il va parcourir 10 fois l'arbre de la racine jusqu'à l'attribut en question.

J'ai testé en parcourant le graphe DOM moi même à la main et de cette manière, je peux par exemple sauver le noeud correspondant à la balise3 et récupérer mes 10 attributs sans tout parcourir. Résultat, je parcours le fichier en quelques secondes.

Mon problème est que pour généraliser l'utilisation de TinyXML, je ne peux pas me permettre de me promener manuellement sur le graphe, il faut que j'utilise XPath.

Franchement, je ne sais pas si c'est normal. Bien sûr, réévaluer le même début d'expression coûte plus cher que ne l'évaluer qu'une fois, mais je ne sais pas si c'est normal que ça prenne autant de temps quand même.

Ce que tu peux faire, c'est un xPath vers le nœud dont tu veux récupérer les attributs, puis en lire les attributs manuellement (ou par un xPath prenant cet élément comme base.)

Tes 45 minutes c'est pour combien d'évaluation XPATH?
Ca me parait complétement démesuré et ça vaut peut être le coup de faire un bench qui évalue quelques milliers de XPATH sur ton fichier entre Xalan, saxon et ta librairie.

Je ne connais pas le nombre exact de requête XPath, à vu de nez je dirais dans les 50 000.

Ouaip, je viens de tester en java un XPATH bien moche "//*[last()]" 50.000 fois sur un xml court mais relativement complexe (un doc word au format XML).
Ca dure dans les 30 minutes :aie:. Mais bon, on lui demande de reparcourir tout l'arbre à chaque fois pour prendre le dernier élement.

Avec un parcourt bien plus direct "/*[1]/*[1]", on revient à 20 secondes et ce, quelque soit la complexité de l'arbre en mémoire.

Quand tu mettais "/Balise1/Balise2/Balise3[indice]/@monAttribut", ça me semble assez direct comme chemin. Le parseur devrait pas reparcourir tout l'arbre en mémoire.
A moins que t'es 50.000 "/Balise1/Balise2/Balise3".

Les balises 1 et 2 ne sont présentes qu'une fois. Par contre la balise de profondeur 3 est présente à peu près 2000 fois. Elle contient quelques attributs à lire et également 2 autres balises de même niveau avec des attributs.

J'ai essayé de mettre en place un système de cache pour sauver le dernier noeud, par exemple ici le noeud de profondeur 3 et accéder directement aux attributs. Ca multiplie par 2 ou 3 la vitesse mais c'est pas satisfaisant.

Au final, je pense que je vais me passer de Xpath. Ou plutôt, vu que mes clés sont fixes, je vais essayer de charger tout le XML dans une map en enregistrant les couples clé/valeur". Ca va coûter en mémoire mais ça devrait être très rapide.

En tout cas, je pensait pas que ça serait aussi long.

Bonjour,

à propos de performance, n'existe t-il pas d'outils pour tester d'éventuels goulots d'étranglement dans une feuille de style XSLT ?

Hello,
Je me suis fait un petit bench sur un xml avec une structure similaire à la tienne et plus de 2000 éléments à un niveau de profondeur et en faisant 50.000 évaluation XPATH.
Extrait du xml :

Code:

---

1 2 3 4 5 6 7 8 9

<?xml version="1.0"?> <root> <node> <node att1="1" att2="2" att3="3"/> <node att1="1" att2="2" att3="3"/> <node att1="1" att2="2" att3="3"/> .... </node> </root>

---

En effet, logiquement on multiplie le temps d'exécution par autant d'attribut qu'on récupère en XPATH.

benchXPATH1 fait juste

Code:

---

/root/node/node[i]

---

Code:

---

1 2 3 4 5

Début benchXPATH1 Wed Sep 01 15:00:56 CEST 2010 Fin Wed Sep 01 15:03:25 CEST 2010 ------------------

---

benchXPATH2 fait bêtement

Code:

---

/root/node/node[i]/att1

---

Code:

---

/root/node/node[i]/att2

---

Code:

---

/root/node/node[i]/att3

---

Code:

---

1 2 3 4 5

Début benchXPATH2 Wed Sep 01 15:03:25 CEST 2010 Fin Wed Sep 01 15:10:47 CEST 2010 ------------------

---

benchXPATH3 fait

Code:

---

/root/node/node[i]

---

Puis récupère les 3 attributs.

Code:

---

1 2 3 4 5

Début benchXPATH3 Wed Sep 01 15:10:47 CEST 2010 Fin Wed Sep 01 15:13:14 CEST 2010 ------------------

---

On voit qu'une fois le noeud sélectionné, on perds très peu de temps à sélectionner les attributs (temps proche de benchXPATH1).

Il y a des travaux de recherche avec quelques algo sur la création d'un plan d'exécution d'un jeu de XPATH pour faire ce genre d'optimisation.
http://www.waset.org/journals/waset/v34/v34-27.pdf
C'est peut être faisable d'en faire un simpliste.
Note quand même que je suis loin des 45 minutes
Bon courage.

Je pense que ça doit varier selon l'implémentation de XPath. Je viens de remplacer mon accès par XPath par un accès à une map remplie au moment de l'ouverture du fichier.

La map prend un peu plus en mémoire, mais le temps d'exécution est bien meilleur. Maintenant la lecture des 50 000 attributs et leur enregistement via consultation de la map me prend que quelques secondes (5 sec à peu près).

Merci votre aide.