[Performances] Array vs DOM vs XPath

Version imprimable

Bonjour à tous,

Je suis en train de développer (pour un stage) une application web qui utilise des données contenues dans un fichier XML de la forme (version simplifiée) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 <reservations> <reservation id="1"> <date>25/08/2009</date> <ville>Paris</ville> </reservation> ... <reservation id="246"> <date>29/08/2009</date> <ville>Toulouse</ville> </reservation> </reservations>
Dans mon code Javascript, je dois accéder plusieurs fois aux valeurs contenus dans ce fichier pour afficher les réservations (en SVG).

Ma première idée (la plus courte à écrire :roll:) a été de stocker tous les noeuds utiles dans des tableaux avec le code suivant :
Code:

1 2 3 var dateTab = xmlDocument.getElementsByTagName("date"); var villeTab = xmlDocument.getElementsByTagName("ville");
Etant donné qu'à chaque fois je traîte toutes les réservations avec une boucle :
Code:

1 2 3 var nbReservations = xmlDocument.getElementsByTagName("reservation").length; for(var i=0; i<nbReservations; i++) {...
je peux récupérer toutes les données d'une réservation en accédant directement aux tableaux :
Code:

1 2 dateTab[i] et villeTab[i]
Dans le code complet, le noeud <reservation> a une vingtaine de fils, et le fichier peut contenir de 20 à 2000 (cas extrême) noeuds <reservation>.

Ma méthode fonctionne, mais il doit y sûrement avoir des solutions plus efficaces, notamment lorsque le nombre de noeuds est très élevé.

Les 2 autres solutions auxquelles j'ai pensé sont :

1) Stocker uniquement la liste des id et à chaque fois que j'ai besoin des données, je fais :
Code:

1 2 3 4 var reservation = xmlDocument.getElementById(idTab[i]); var date = reservation.firstChild; var ville = reservation.firstChild.nextSibling; (ou .lastChild)
2) Même méthode que la précédente, mais en utilisant XPath.

J'espère que mes explications sont assez claires et pas trop ennyeuses.

Pour résumé : je voudrais savoir s'il y a une méthode optimale pour ce genre de traîtements.
J'avais utilisé les tableaux par feignantise :oops: et aussi par ce qu'accéder à un champ d'un tableau me semblait le plus rapide (en terme de performances). Cependant, stocker autant de données n'est peut-être pas conseillé (notamment par mon patron ;)), ce qui m'a poussé à m'interroger sur les autres solutions.

J'espère qu'il y aura quelques courageux pour me lire jusqu'au bout :P

Merci d'avance,
b0u31

27/08/2009, 13h59
kernelfailure

Bonjour,

Qu'entends-tu par un noeud utile ?

Tu parles d'accéder plusieurs fois au fichier pour afficher les réservations. Peut-on penser que tu utilises une pagination de l'affichage.

J'ai du mal à saisir la procédure et le besoin de ton stockage intermédiaire.
27/08/2009, 14h25
BaBeuH

Bonjour,

Par rapport aux performances, je te conseille de faire des tests pour chaque méthode avec un chrono pour voir la durée d'exécution de chaque méthode.

Je dirai que les méthodes Tableau (ta 1ère méthode) et DOM (stockage des id puis accès via le DOM) doivent être globalement équivalentes en termes de performance. Le principe du DOM étant de charger en mémoire (ce qui peut être lourd si le XML est important ?) le document XML, mais une fois chargé, l'accès est, en principe, trés rapide.

Pour la méthode tableau, le fait de stocker autant de données ne me semble pas "dramatique" sauf si le document XML est amené à être modifié (désynchro du tableau par rapport au XML) ?

Pour le XPath, j'avoue ne pas connaître suffisamment les méthodes javascript de manipulation xpath...

Après, je rejoins effectivement kernelfailure pour savoir quel est exactement ton besoin par rapport à ton XML ? Générer un svg à partir des données XML ?

A+
27/08/2009, 14h45
franculo_caoulene

Salut,

Cherches-tu à tout afficher d'un coup ou à accéder au fichier xml comme une base de données? Quelles technologies sont utilisées?
27/08/2009, 17h58
b0u31

Merci d'avoir pris le temps de me lire :)

Citation:

Envoyé par kernelfailure

Qu'entends-tu par un noeud utile ?

Parmis tous les noeuds fils de <reservation>, il y en a certains que je ne récupère pas, car ils ne me servent pas. C'est juste un détail inutile (:ccool:), que je n'aurai pas du mettre...

Je vais détailler un peu plus mon application :

Il s'agit d'un planning de réservations en SVG, dont on peut modifier dynamiquement (sans recharger la page) la date de début et de fin, et donc le nombre de jours affichés.
A chaque fois que j'ajoute un jour, je fais une requête AJAX pour aller chercher les réservations de ce jour et je mets à jour le fichier XML qui contient toutes les réservations. Je reremplis alors tous mes tableaux avec les nouvelles données, je supprime complètement l'affichage actuel des réservations, et je recrée toutes les réservations avec ces nouvelles données.

Les accès et les mises à jours sont donc fréquents.

C'est une explication un peu simplifiée, car en réalité je mets en cache les données des jours suivants pour accélérer l'affichage (sans attendre la réponse de la requête AJAX).
Seules les réservations qui ont une date inclue dans la période affichée par la planning sont créées (et affichées), mais je parcours quand même l'ensemble du fichier XML, car elles ne sont pas triées par date.

Lorsque je parle de créer une réservations, il s'agit de créer une instance de la classe Reservation (puisque je travaille en Javascript orienté objet) qui ajoute aussi des noeuds dans l'arbre DOM du document SVG.

Voilà, j'espère vous avoir un peu plus éclairés. Si vous avez d'autres questions, n'hésitez pas...
27/08/2009, 20h04
kernelfailure
Ce qui me semble être le plus lourd, c'est le rafraichissement complet par XML.

Des méthodes remove(child), update(child) et append(child) pourraient être utilisées, aussi bien sur ton client que sur le serveur.

Le soucis, dans un cas comme dans l'autre, viendrait du fait que plusieurs utilisateurs puissent modifiier la base. Donc là, il faut un notificateur de MAJ qui, par exemple, servirait à récupérer à périodicité régulière un timestamp de dernière MAJ.
Idéalement, un timestamp d'état pour chaque id serait une bonne chose. Ainsi tu pourrais mettre à jour le client pour les id sont le timestamp est >= au timestamp de notification.
Du coup, tu pourrais aussi intercepter d'éventuelles collisions de modification.
C'est sans doute hors propos... Je m'égare :roll:

Un tableau ? Je dirait que tu en a déjà un : XML. ;)

Néanmoins, pour accélérer les accès en recherche, tu pourrais créer un tableau d'ids pour les dates et villes du type :
Code:

1 2 byCity.push([ville,[ids...]]) byDate.push([date,[ids...]]) // Au format ISO !!
Ce qui te permettrait des tris :
Code:

1 2 var byCity=[['Toulouse',[2,4,7]],['Paris',[3,6,8]],['Lille',[1,5]]]; byCity.sort(function(a,b){return a[0]>b[0]}); // Asc
...Et de proposer des listes de choix pour n'afficher que les ids concernés.
Il peut s'agir d'un seul et même tableau, pour un tagName désigné ;)

Finalement, ce qui serait tout de même mieux, serait que tu ais un service qui te retourne un XML trié des dates ou des villes disponibles, et qu'une fois la sélection effectuée, tu récupères un XML filtré. Ca limiterait la volumétrie. :ccool:
27/08/2009, 21h01
b0u31

Citation:

Envoyé par kernelfailure

Ce qui me semble être le plus lourd, c'est le rafraichissement complet par XML.

Des méthodes remove(child), update(child) et append(child) pourraient être utilisées, aussi bien sur ton client que sur le serveur.

Tu parles du rafraichissement de l'arbre DOM du document SVG (suppression complète, mise à jour, reconstruction des réservations) ? ou du rafraichissement du fichier XML ?

Dans le 1er cas : c'est une méthode un peu "bourrine", mais pour l'instant elle me (et à mon patron) convient, car les performances sont correctes.
Il y a pas mal de difficultés liées à d'autres éléments du planning, qui font que pour l'instant j'ai gardé cette solution. Cependant, c'est un des aspects qui sera à améliorer lorsque l'ensemble du projet sera fonctionnel.

Dans le 2ème cas : Je ne rafraichis pas complètement le fichier XML, j'ajoute les nouveaux noeuds à la fin du fichier existant et j'utilise XPath pour filtrer les éventuelles répétitions.

J'aime bien ton idée de trier les données avec des tableaux d'ids pour la date (ce qui me sert le plus) :)

Trier directement (côté serveur) les données selon la date est aussi intéressant et permettrait d'alléger le travail côté client.

Au final, si j'ai bien compris, tu me conseilles soit de trier les données côté client et d'utiliser des tableaux, soit de trier les données côté serveur et de n'utiliser que le fichier XML (avec DOM et/ou XPath) ?

Encore merci !
28/08/2009, 11h11
franculo_caoulene

Tu devrais faire le maximum de traitements coté serveur. Le rôle du serveur est de traiter, celui du client d'interagir. Le serveur devrait fournir des données immédiatement utilisables par le client.
28/08/2009, 16h24
b0u31

Ok, merci beaucoup pour vos réponses :D

Est-ce que vous auriez des articles "sérieux" qui comparent les performances de Javascript, notamment les fonctions DOM ?

J'en ai trouvé quelques uns, mais ils fournissent surtout des astuces (parfois contredites) pour améliorer les performances et non pas des résultats chiffrés de tests :
- 3 performance tips for Javascript
- High performance AJAX applications
- DOM performance
- Increase DOM node insertion performance
- Dev Opera - Efficient Javascript

Donc si vous en avez d'autres un peu plus consistants, je suis preneur :)

Encore merci.

Bye,
b0u