🚀 go-pugleaf

CrazyCat a �crit :
> Bonjour,
> 
> Je ne sais pas si ce groupe convient pour ma question, mais je tente 
> quand m�me, quelqu'un saura bien m'aiguiller vers le bon groupe si 
> n�cessaire :)
> 
> Je dois proc�der � des transformations xsl sur des fichiers xml, jusque 
> l� que du normal.
> Pour se faire, j'utilise xsltproc et �a fonctionne plut�t bien avec des 
> fichiers XML allant jusqu'� 100Mo. Mais au dessus (il y en a un de 
> 800Mo), �a prend toute la m�moire de la machine et semble m�me tout 
> bloquer.

   Par curiosit� je suis all� voir le source de xsltproc, libxslt, et 
libxml. Et effectvement, le parser analyse le fichier d'un coup, et 
concerve les arbres des diff�rents documents XML.

> Avez-vous une astuce pour traiter les xml sans les charger compl�tement 
> en m�moire ou dois-je me r�soudre � scinder les gros fichiers en des 
> entit�s plus petites ?

   Si c'est urgent, certainement. Maintenant il doit bien exister un 
parser qui soit capable de g�rer des gros fichiers de mani�re efficace. 
Mais trois (sablotron, expat et xsltproc) que j'ai regard� n'en semble 
pas capable.

-- 
Micka�l Wolff aka Lupus Michaelis
http://lupusmic.org

CrazyCat <crazycat@c-p-f.org> writes:

> Je dois procéder à des transformations xsl sur des fichiers xml,
> jusque là que du normal.
> Pour se faire, j'utilise xsltproc et ça fonctionne plutôt bien avec
> des fichiers XML allant jusqu'à 100Mo. Mais au dessus (il y en a un de
> 800Mo), ça prend toute la mémoire de la machine et semble même tout
> bloquer.
>
> Avez-vous une astuce pour traiter les xml sans les charger
> complètement en mémoire ou dois-je me résoudre à scinder les gros
> fichiers en des entités plus petites ?

Ca dépend trop de la transformation XSLT : il suffit d'un //, d'un
<xsl:sort>, etc. pour qu'on ne puisse plus s'épargner le chargement en
mémoire. A ma connaissance, Xalan avait le projet de faire cela (il y a
longtemps), mais je crois qu'ils ont laissé tomber rapidement. Je ne
connais pas de processeur XSLT qui implémente cela.

Si ta transformation est suffisamment simple, ou si tu dois extraire un
morceau du fichier, je te conseille d'écrire cela a la mano avec SAX (au
moins pour la partie extraction).

-- Alain.

Merci Micka�l et Alain de vos r�ponses.

Micka�l Wolff wrote:
>> Avez-vous une astuce pour traiter les xml sans les charger 
>> compl�tement en m�moire ou dois-je me r�soudre � scinder les gros 
>> fichiers en des entit�s plus petites ?
>   Si c'est urgent, certainement. Maintenant il doit bien exister un 
> parser qui soit capable de g�rer des gros fichiers de mani�re efficace. 
> Mais trois (sablotron, expat et xsltproc) que j'ai regard� n'en semble 
> pas capable.

Finalement, je traite "� la main" le fichier en le lisant ligne par 
ligne afin de recr�er chaque node et je le parse � ma ma mani�re (en 
perl), ce qui est bien plus rapide.

J'ai essay� de faire des fichiers xml plus petits mais entre la cr�ation 
et le traitement par xslproc, je consomme bien trop de ressources 
machine et de temps. Parfois, le plus simple est le mieux.

-- 
R�seau IRC Francophone: http://www.zeolia.net
Aide et astuces : http://www.g33k-zone.org
Communaut� Francophone sur les Eggdrops: http://www.eggdrop.fr

Bonjour,

En fait, il est possible d'optimiser le traitement tout en restant
compatible XML

Nous faisons des formations et l'intégration des outils pour faire
ceci

Cordialement,

Xmlizer

On 17 nov, 17:31, CrazyCat <crazy...@c-p-f.org> wrote:
> Bonjour,
>
> Je ne sais pas si ce groupe convient pour ma question, mais je tente
> quand même, quelqu'un saura bien m'aiguiller vers le bon groupe si
> nécessaire :)
>
> Je dois procéder à des transformations xsl sur des fichiers xml, jusque
> là que du normal.
> Pour se faire, j'utilise xsltproc et ça fonctionne plutôt bien avec des
> fichiers XML allant jusqu'à 100Mo. Mais au dessus (il y en a un de
> 800Mo), ça prend toute la mémoire de la machine et semble même tout bloquer.
>
> Avez-vous une astuce pour traiter les xml sans les charger complètement
> en mémoire ou dois-je me résoudre à scinder les gros fichiers en des
> entités plus petites ?
>
> Pour info, la machine fonctionne sous Fedora.
>
> Merci d'avance.
>
> --
> Réseau IRC Francophone:http://www.zeolia.net
> Aide et astuces :http://www.g33k-zone.org
> Communauté Francophone sur les Eggdrops:http://www.eggdrop.fr

xmlizer wrote:
> En fait, il est possible d'optimiser le traitement tout en restant
> compatible XML

Je ne suis pas s�r de comprendre. En restant compatible XML, oui, on 
s'en doute, mais en restant compatible XSLT ?


--
Mayeul

CrazyCat wrote:
> Bonjour,
> 
> Je ne sais pas si ce groupe convient pour ma question, mais je tente 
> quand m�me, quelqu'un saura bien m'aiguiller vers le bon groupe si 
> n�cessaire :)
> 
> Je dois proc�der � des transformations xsl sur des fichiers xml, jusque 
> l� que du normal.
> Pour se faire, j'utilise xsltproc et �a fonctionne plut�t bien avec des 
> fichiers XML allant jusqu'� 100Mo. Mais au dessus (il y en a un de 
> 800Mo), �a prend toute la m�moire de la machine et semble m�me tout 
> bloquer.
> 
> Avez-vous une astuce pour traiter les xml sans les charger compl�tement 
> en m�moire ou dois-je me r�soudre � scinder les gros fichiers en des 
> entit�s plus petites ?
> 
> Pour info, la machine fonctionne sous Fedora.
> 
> Merci d'avance.
> 

Bonjour,

j'imagine que le XSLT ne traite pas toutes les donn�es; pourquoi alors 
ne pas stocker ce gros fichier dans une BD native XML, et utiliser 
XQuery pour l'extraction de la partie utile � la transformation ?

-- 
Cordialement,

               ///
              (. .)
  --------ooO--(_)--Ooo--------
|      Philippe Poulard       |
  -----------------------------
  http://reflex.gforge.inria.fr/
        Have the RefleX !

Oui compatible XSLT 2 aussi
La version payante de Saxon permet de faire un certain nombre de
traitement en streaming, mais cela dépends de tellement de paramètre
qu'il m'est impossible de répondre définitivement que cela
fonctionnera

Xmlizer

On 19 nov, 13:16, Mayeul <mayeul.marg...@free.fr> wrote:
> xmlizer wrote:
> > En fait, il est possible d'optimiser le traitement tout en restant
> > compatible XML
>
> Je ne suis pas sûr de comprendre. En restant compatible XML, oui, on
> s'en doute, mais en restant compatible XSLT ?
>
> --
> Mayeul