Discussion :

[toontoon]

Bonjour,

J'utilise actellement DOM pour faire de la comparaison de méta données en 2 applications.
Je générè un fichier XML de 5 MO que l'on appellera source.xml qui provient de l'application 1.
Je générè un fichier XML de 5 MO que l'on appellera dest.xml qui provient de l'application 2

Ensuite, sous une application web (serveur tomcat), je charge grâce à DOM un arbre (Arbre 1)en mémoire qui réprénsete source.xml, puis un second arbre (Arbre 2) en mémoire qui réprésente dest.xml.

Ensuite je parcours mon arbre 1. Pour chaque élément de l'arbre 1 je regarde s'il existe dans l'arbre 2. etc... et je génére un 3 ième arbre que je sauvegarde en fin de traitement.

Tout ceci se passait plutôt pas trop mal avec 256 Mo de RAM. Seulement voilà, à présent mes fichiers ont plus que doublé (ils font 12 Mo chacun) et je me retrouve avec des out of memory dans tous les sens.

Vous allez me dire : utilise SAX : Oui mais je ne vais pas parser le dest.xml pour chaque objet de source.xml.

Mon idée serai peut-être de faire un chargement partiel ou quelquechose d'autre mais tout en restant avec du XML...

Merci d'avance pour vos réponses

[GrandFather]

Bonjour,

plutôt que refaire un algo de comparaison, pourquoi ne pas utiliser une librairie ? Tu devrais jeter un coup d'oeil à JXyDiff, dont il est question notamment dans ce post.

[toontoon]

Merci, je vais jeter un oeil...

[yjuliet]

Quoi qu'il en soit, le problème risque de ne pas venir directement du fait que tu ais 256 Mo de RAM. Même sur des serveurs avec 3 Go de RAM, j'obtiens la même erreur si l'application est un peu gourmande et que le paramétrage de Tomcat n'attribue pas suffisemment de mémoire à la machine virtuelle Java.

Je pense qu'il faut aussi regarder de ce côté là.

[toontoon]

Le truc, c'est que je ne souhaite pas allouer plus de mmoire pour mon application . Il faut que je me débrouille pour rester dans la même configuration mémoire pour faire celà.

Ne t'inquiète pas que si je lance mon tomcat en changeant les paramètres de la VM, pas de soucis ça passe en 512. mais si dans 1 moi mon fichier double, je devrai passer à 1024 ? Ce n'est pas envisageable pour mon appli

[yjuliet]

Si tu as déjà des problèmes de mémoire au niveau de ton serveur d'applis, il faudra de toutes manières que tu adaptes la configuration (dans les fichiers de conf, pas sur la mémoire physique) aux besoins de l'application. Tomcat limite par défaut pas mal les ressources disponibles pour chaque application, c'est ça qu'il faut modifier, ne serait-ce que pour avoir la place de charger tes fichiers XML en mémoire ...

Second élément, il va falloir faire les choses à la mode des années 80 : optimiser l'utilisation mémoire de ton programme... c'est à dire ne lui faire charger que le nécessaire, ré-utiliser les objets volumineux (supprimer au fur et à mesure les noeuds parcourus dans la source/destination, ou les déplacer vers le 3ème arbre au lieu de les copier ?)
En bref, tu vas avoir à faire un compromis entre la rapidité d'exécution et l'occupation mémoire...
Tant que tu voudras construire ton arbre destination à partir de 2 sources, tu occuperas (au plus, juste pour le stockage des arbres) 3x la taille de ton arbre le plus lourd.
Quand tes arbres pesaient 5 Mo, l'appli utilisait 15 Mo. Maintenant avec tes fichiers de 12 Mo, elle utilise 36 Mo, quand tes fichiers feront 100 Mo, elle utilisera 300 Mo, du moins elle plantera parce qu'elle n'aura pas ses 300 Mo disponibles.

[toontoon]

Si tu as déjà des problèmes de mémoire au niveau de ton serveur d'applis, il faudra de toutes manières que tu adaptes la configuration (dans les fichiers de conf, pas sur la mémoire physique) aux besoins de l'application. Tomcat limite par défaut pas mal les ressources disponibles pour chaque application, c'est ça qu'il faut modifier, ne serait-ce que pour avoir la place de charger tes fichiers XML en mémoire ...

Second élément, il va falloir faire les choses à la mode des années 80 : optimiser l'utilisation mémoire de ton programme... c'est à dire ne lui faire charger que le nécessaire, ré-utiliser les objets volumineux (supprimer au fur et à mesure les noeuds parcourus dans la source/destination, ou les déplacer vers le 3ème arbre au lieu de les copier ?)
En bref, tu vas avoir à faire un compromis entre la rapidité d'exécution et l'occupation mémoire...
Tant que tu voudras construire ton arbre destination à partir de 2 sources, tu occuperas (au plus, juste pour le stockage des arbres) 3x la taille de ton arbre le plus lourd.
Quand tes arbres pesaient 5 Mo, l'appli utilisait 15 Mo. Maintenant avec tes fichiers de 12 Mo, elle utilise 36 Mo, quand tes fichiers feront 100 Mo, elle utilisera 300 Mo, du moins elle plantera parce qu'elle n'aura pas ses 300 Mo disponibles.

Peux-tu me donner une piste pour la modification de la mémoire alloué à 1 application sous tomcat ? Je ne connais pas bien ces paramètres. Je connais le -Xmx pour le tomcat lui même.

D'autre part, supprimer les "noeuds traités" dans l'arbre 1 & 2 semblent être un excellente idée pour accélerer les process... Je me demande comment j'ai fait pour passer à côté...

Je vais me remettre particulièrement demain sur ce point.

Merci pour ton aide.

[toontoon]

oula, je viens d'halluciner. J'ai mis les traces de la VM à chaque chargement de fichier

pour un fichier de 11 Mo, la VM prends 110 MO de mémoire en plus

c'est normal ça ?

[toontoon]

J'ai trouvé 2 API :

QDOM & PDOM qui semble être utlra rapide par contre il semble y avoir moult bugs et c'est des API sharware