Discussion :

[Ikki_2504]

Bonjour,

Je développe une appli qui lit des infos dans un fichier XML.
Ce fichier XML risque de grossir de manière exponentielle au fil du temps, mais ne devrait jamais dépasser les 10.000 ou 15.000 lignes.

Je souhaiterais savoir si les requêtes XPath que je lance sur ce fichier vont devenir vraiment lentes lorsque ce dernier aura atteint plusieurs milliers de lignes ?

Merci

[thelvin]

Cela dépend de la complexité de tes requêtes xPath et de la profondeur des imbrications.
Des xPath complexes peuvent rendre ça infiniment lent, oui.
Une faible profondeur d'imbrication en réduit beaucoup les risques.

Forcément, plus c'est gros, plus c'est long. Mais 10.000 ou 15.000 lignes c'est pas énorme.

Accessoirement, comme le signale souvent Erwy, c'est l'occasion de se débarrasser des //truc ou machin//truc ou des descendant::machin

[Ikki_2504]

A vrai dire, j'ai découvert XPath il y a une dizaine de jours (en faisant ce projet justement), donc j'aurai du mal à dire si mes requêtes sont si complexes que ça.

Exemple :
//Event[SaveDate[contains(., '{0}')] and Finished='{1}']
ou encore
//Event[SaveDate[starts-with(., '{0}')] or SaveDate[starts-with(., '{1}')]

Aucune ne me semble plus "complexe" que cela, a part une qui a 6 "or" à la suite...


A propos de ta dernière phrase... "se débarrasser des //truc" ... Peut-tu préciser comment améliorer ça ?

[thelvin]

A propos de ta dernière phrase... "se débarrasser des //truc" ... Peut-tu préciser comment améliorer ça ?

Remplacer par /le/chemin/clair/et/precis/vers/le/truc et tu seras ok. Pas de //, c'est cher sur les gros fichiers.

[Erwy]

Accessoirement, comme le signale souvent Erwy, c'est l'occasion de se débarrasser des //truc ou machin//truc ou des descendant::machin

Je dirais qu'en ordre de coût général croissant on a :

1. child/parent
2. following-sibling/preceding-sibling
3. following/preceding
4. descendant/descendant-or-self
5. Xpath avec un prédicat contenant lui même un xpath de type 2 à 4

Si on est dans du XSLT deux autres conseils

• quand c'est possible utilisez des algo utilisant des xsl:key
• privilégiez toujours les XPath relatif au noeud courant

je plussoie thelvin 10000 ou 15000 lignes ce n'est pas forcemment énorme.
La problématique , comme pour un sgbdr , est moins le nombre d'enregistrement ou de "lignes" que :
- la complexité de la requête
- la complexité de la structure de donnée
- la "taille" d'une ligne

[Ikki_2504]

Merci des réponses

Donc si j'ai bien compris (ce qui n'est pas certain )

Mon document XML étant structuré de manière très simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<?xml version="1.0" encoding="utf-8"?>
<EventList>
  <Event ID="0">
    <A>valeurA</A>
    <B>valeurB</B>
    <C>valeurC</C>
    <D>valeurD</D>
    <E>valeurE</E>
  </Event>
  <Event ID="1">
    ...
  </Event>
<EventList>

... Ma requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

//Event[C[contains(., '{0}')] and D='{1}']

doit être remplacée par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

//EventList/Event[C[contains(., '{0}')] and D='{1}']

histoire d'être plus efficace ?

[Erwy]

... Ma requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

//Event[C[contains(., '{0}')] and D='{1}']

doit être remplacée par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

//EventList/Event[C[contains(., '{0}')] and D='{1}']

histoire d'être plus efficace ?

NON, c'est la même chose c'est par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/EventList/Event[C[contains(., '{0}')] and D='{1}']

thelvin >> j'espère que tu ne l'as pas trop mal pris hier mais tu peux constater l'ampleur du problème

[Ikki_2504]

C'est la même chose c'est bien ce qu'il me semblait ...

Donc c'est la réponse de thelvin que je n'ai pas compris

"Remplacer par /le/chemin/clair/et/precis/vers/le/truc et tu seras ok. Pas de //, c'est cher sur les gros fichiers. "
=> Ça ne s'applique donc pas sur MON fichier ?

[Erwy]

/truc et tu seras ok. Pas de //, c'est cher sur les gros fichiers. "
=> Ça ne s'applique donc pas sur MON fichier ?

si mais le code XPath que tu viens de donner comprenait un // relis toi

//EventList/Event[C[contains(., '{0}')] and D='{1}']
alors que c'est
/EventList/Event[C[contains(., '{0}')] and D='{1}']

[thelvin]

"Remplacer par /le/chemin/clair/et/precis/vers/le/truc et tu seras ok. Pas de //, c'est cher sur les gros fichiers. "
=> Ça ne s'applique donc pas sur MON fichier ?

Ben non... Tu me l'avais pas montré ton fichier, je pouvais pas deviner le chemin.

thelvin >> j'espère que tu ne l'as pas trop mal pris hier mais tu peux constater l'ampleur du problème

Je ne l'ai pas pris mal ni ne laisse s'installer un quelconque mauvais sentiment, mais je ne suis pas d'accord avec l'idée que j'aurais dû tourner mon message autrement. En revanche, je trouve bénéfique que ça ait été abordé après, par quelqu'un d'autre, après que le cœur de la question ait été abordé.
Mais ça va être long si je dois dire pourquoi.

[Ikki_2504]

Ah oui exact, faute d'inattention.

Bon ok maintenant j'ai compris, merci à vous deux