XML DOM et gros fichiers

Bonjour a tous, j'ai lut il y a peu sur ce forum que non, le XML DOM ne plantait pas avec de gros fichiers... toujours est il, qu'il a apparament beaucoup de mal....

Voila le probleme, faites le test...

J'ai chargé la specif xsl (disponible auformat XML sur le site du W3C) qui fait environ, 1,53 Mo, avec l'implémentation version 4.0 du DOM de MS. le tout trasformé avec une feuille de style generique plutot simple. resultat :

IE 6 mouline pendant quelque temps (environ 1 mniutes sur une machine a 1,5Ghz) l'utlisation mémoire passe a environ 200Mo pour ie, la transformation s'affiche, mais le programme ne réponds plus et continu a mouliner a raison de 99% d'util proc. et puis voila cadure pendant 5 ou 6 minutes, et apres oligé de tuer le processus parce que ca reste bloquer.

Avez vous rencontrer le meme genre de pbs ? ou au contraire tout marche t'il très bien pour vous ? aurais-je fait une erreur dans l'utilisation du DOM ?

De plus si quequ'un a des fichiers xml tests contenant n'importe koi (sauf des données confidentielles evidement) de diverses tailles (entre 50 et 500 Ko par exemple) merci de me les faire parvenir par mail, afin que je puisse effectuer de plus amples tests...

Toujours est il que l'implémentation du DOM de Microsoft me parait plustôt lente (pas parceque c'est MS je pense, mais simplement parcequ'il s'agit de manipuler du xml...)

Voila, si quelqu'un à des expériences similaires ou différentes a me faire partager, je suis preneur.

d'avance merci.

Salut !
Effectivement, dans le cas de gros fichier, le parsing peut utiliser au max ton UC. J'ai en effet constaté ce problème, ayant eu à traiter de gros fichiers (+ de 3500 fichiers...certain faisant pas loin d'1 meg), que je ne peux te transmettre car ils sont malheureusement confidentiels. La solution simple est d'augmenter au max la mémoire virtuelle sur ton pc de prod lors de ton traitement. Il n'est pas possible, à ma connaissance, de faire autrement avec cette méthode(cf. ce que t'as expliqué Nicolas Cuny).
A+ :wink:

Citation:

---

Envoyé par Nicolas Cuny

Salut,

Dire que DOM plante ou ne plante pas n'a aucun sens.

---

Autant pour moi, je me suis mal exprimé, je parlais de l'implementation de microsoft, que ce soit celle fournie avec le parser 3.0 ou le 4.0 qui, d'apres Microsoft est en moyenne de 2 a 4 x plus rapide que la version précédente. merci toutefois pour la rectification.

effectivement, il me semblait bien que SAX ne permettait pas de manipulation complexes sur les fichiers.

Hors, c'est justement ce qu'il me faut (pas de bol hein :( ) Mais mission, est en fait de développer un editeur XML online, sans installation de plug-in aucun, et compatible IE 5.5 ou 6. Les fichiers à éditer sont en fait de gros "livres multimédia et interactifs" stockés dans une vbase de données et je dois permettre aux auteurs d'éditer ces documents via une interface WYSIWYG...

Et ce qui me fait peur, ce n'est pas trop la façon de faire, j'ai déjà une bonne idée de la marche a suivre, mais plutot, les performances finales qui risquent d'être plutot maigres...

En effet l'augmentation de la mémoire virtuelle peut permettre de mener a bien l'opération sans blocage de la machine, cependant, sachant que je veux mettre a jour mon arbre xml dès qu'un élément est modifié, il faut que le tout s'effectue relativement vite...

que dirions nous s'il fallait attendre 30 secondes après avir taper une phrase dans Word ???

Une des solutions qui m'apparait alors, serait de ne charger que de petites parties du document XML (par chapitre, paragraph ou autre...)
le problème est maintenant de savoir, si mon document n'est pas entier, si mon fragment pourra toujours être validé par exemple...

Une implémentation en C++ ou C# via un activex par exmple (donc compilé, mais nécessitant une installation) serait elle plus beaucoup plus rapide ?

Bref, autant de questions aui se posent a moi...
merci toutefois pour vos réponses.

"Une implémentation en C++ ou C# via un activex par exmple (donc compilé, mais nécessitant une installation) serait elle plus beaucoup plus rapide ? "
C'est amusant :D , car justement, mon expérience est celle-ci. J'ai crée un ocx en C++ permettant de traiter les fichiers xml d'une part, fait la transformation xslt d'autre part . l'affichage se fait sur un navigateur via le résultat de la transformation xslt.
Alors, oui, le traitement est plus rapide (je n'ai pas les chiffres en tête, mais à l'époque -le dévelloppement date d'un an, à peu près-nous avions fait des tests comparatifs de performance sur plusieurs machines de capacité différentes. Effectivement, le rendement était vraiment bien meilleur.
"Une des solutions qui m'apparait alors, serait de ne charger que de petites parties du document XML (par chapitre, paragraph ou autre...) "
pourquoi pas, si tu peux facilement identifier et morceller tes fichiers xml!
En tout cas, cette méthode fonctionne, et de plus, tu as toute l'aide nécessaire pour le réaliser sur la msdn.
Mais là encore, il est possible que ce type de développement ne corresponde pas exactement à ton besoin, et il existe peut-être des solutions plus récentes pour répondre à ton problème.
En espérant avoir pu t'éclairer !
A+!

Juste pour dire, notre produit manipule des XML faisant 2 Mo et, même si la mémoire est saturée et/ou que c'est lent, MSXML s'en sort plutôt bien.

Quand à IE, le fait est qu'il ne se contente pas de charger le XML, il le transforme pour le présenter (avec coloration syntaxique, etc...). Ce qui fait que ça ralenti encore +