IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

XML/XSL et SOAP Discussion :

Problème de perf TinyXPath


Sujet :

XML/XSL et SOAP

  1. #1
    Membre régulier
    Inscrit en
    Juillet 2008
    Messages
    62
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 62
    Points : 104
    Points
    104
    Par défaut 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.

  2. #2
    Membre expérimenté
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 466
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 466
    Points : 1 610
    Points
    1 610
    Par défaut
    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.

  3. #3
    Membre régulier
    Inscrit en
    Juillet 2008
    Messages
    62
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 62
    Points : 104
    Points
    104
    Par défaut
    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.

  4. #4
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 547
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 547
    Points : 21 602
    Points
    21 602
    Par défaut
    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.)
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre expérimenté
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 466
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 466
    Points : 1 610
    Points
    1 610
    Par défaut
    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.

  6. #6
    Membre régulier
    Inscrit en
    Juillet 2008
    Messages
    62
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 62
    Points : 104
    Points
    104
    Par défaut
    Je ne connais pas le nombre exact de requête XPath, à vu de nez je dirais dans les 50 000.

  7. #7
    Membre expérimenté
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 466
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 466
    Points : 1 610
    Points
    1 610
    Par défaut
    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 . 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".

  8. #8
    Membre régulier
    Inscrit en
    Juillet 2008
    Messages
    62
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 62
    Points : 104
    Points
    104
    Par défaut
    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.

  9. #9
    Membre émérite
    Avatar de polymorphisme
    Homme Profil pro
    Publishing
    Inscrit en
    Octobre 2009
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Publishing
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2009
    Messages : 1 460
    Points : 2 371
    Points
    2 371
    Par défaut
    Bonjour,

    à propos de performance, n'existe t-il pas d'outils pour tester d'éventuels goulots d'étranglement dans une feuille de style XSLT ?
    Article : Installation de Cocoon
    Je ne réponds pas aux MP à caractère technique.

  10. #10
    Membre expérimenté
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 466
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 466
    Points : 1 610
    Points
    1 610
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    /root/node/node[i]/att1
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    /root/node/node[i]/att2
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    /root/node/node[i]/att3
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 Puis récupère les 3 attributs.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  11. #11
    Membre régulier
    Inscrit en
    Juillet 2008
    Messages
    62
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 62
    Points : 104
    Points
    104
    Par défaut
    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.

Discussions similaires

  1. Problème de perf sous Tomcat 5.5
    Par gamodio dans le forum Tomcat et TomEE
    Réponses: 14
    Dernier message: 18/07/2006, 12h48
  2. [VBA-E] Problème de perf'
    Par MatMeuh dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 05/07/2006, 17h22
  3. Réponses: 11
    Dernier message: 19/06/2006, 17h54
  4. problèmes de perfs IE6/Firefox
    Par fredoche dans le forum Général JavaScript
    Réponses: 0
    Dernier message: 26/08/2005, 18h44
  5. Problème de perfs Sous requetes IN
    Par ias83 dans le forum SQL
    Réponses: 4
    Dernier message: 15/06/2005, 13h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo