Discussion :

[autousto]

Bonjour,

Je travaille sur des documents XML assez volumineux, je dois proposer une solution technique pour remplacer le processus actuel qui prend beaucoup de temps (jusqu'à 5h de traitement pour un document xml), et j'hésite entre deux langages Python et Java.

Pourriez-vous m'aider et me dire lequels des deux et plus performant, juste au niveau performance avec le traitement des XML, sans prendre en compte la lisibilité du code, ou la portabilité ....

Je vous remercie par avance.

[wiztricks]

Salut,

Telle que posée, la question n'a pas trop de sens.

Avec Java, une bibliothèque XML sera probablement écrite en Java.
Avec les versions récentes de Python, les bibliothèques standards proposent du Python (lent) ou en C.

Après vous pouvez prendre une libxml2 et utiliser la même librairie avec Python/Java: il suffit d'installer le "binding".
Dans ce cas, le temps CPU consomme dépendra des traitements "pur" Java ou "pur" Python et a traitement équivalents Python sera probablement moins bon.

une solution technique pour remplacer le processus actuel qui prend beaucoup de temps (jusqu'à 5h de traitement pour un document xml), et j'hésite entre deux langages Python et Java.

"le temps CPU consomme" dépendra du temps passe a attendre les fins d’entrée sortie: 5h c'est long mais si vous passez 95% du temps
a attendre la fin des ES, changer de langage sera beaucoup de boulot pour rien. Des disques plus rapides (on fait du SSD pas cher) permettra d'obtenir des résultats rapidement, pour quelques centaines d'Euros de matos

=> La question est de savoir comment sont stresses CPU, Memoire et IO durant ces 5h.

Si c'est 80% de temps CPU, il faudrait peut être revoir les algos, les flux de traitements, paralléliser,...
Et se poser la question du langage "après".

- W

[emmanuel_dumas]

Bonjour

Je n'irais pas jusqu'à dire que la question n'a pas de sens, par contre, elle relève beaucoup de piège.

Si j'ai bien compris, le premier problème, c'est une analyse de fichier XML qui prend 5h, cela parait trop long. Est-il possible de quantifier la taille des données d'entrées XML pour que le lecture du forum puisse comparer ces résultats a son expérience ? Dans mon cas, lecture de fichier XML en python avec ElementTree, je n'ai jamais eu le moindre de soucis de performance pour des fichiers de 10 000 lignes, le traitement m'a toujours paru quasi instantanée.

En général, quand un traitement est trop long, la première question à se poser est : est-ce que l'algorithme utilisé est le bon ? et indirectement pourquoi c'est long ? La réponse peut-être, en autre, qu'il s'agit d'accès E/S long, et effectivement dans ce cas, c'est plutôt vers du changement de hard qu'il faut s'orienter. Dans tous les cas, quelques informations sur ce point aidera à apporter les bons éléments de réponse. Par exemple, vu mon expérience, j'ai du mal à croire que la simple lecture de données XML puisse prendre 5h, sauf si les données sont gigantesques, et alors en général là on est soumis à un problème de mémoire, ce qui déclenche le swap, et alors ralentie énormément le traitement. Dans ce cas, il faut revoir l'algorithme pour traiter les données par petit lot. Bien sur, sans plus de précision, tout cela ne sont que des spéculations.

Maintenant admettons que l'algorithme utilisé soit le bon et qu'il s'agit surtout de charge CPU.
Quand on souhaite changer de langage de programmation pour accélérer un traitement, en général on étudie la question du C/C++ plutôt que Python ou Java. Est-ce que cette piste a été étudiée ? Si oui, pourquoi elle été écartée ? Ces raisons aideront à trouver la bonne solution entre le Java et Python.

Dernier point, il est demandé de ne se prononcer que sur l'aspect performance, et je l'admet je me prononce un peu près sur tout, sauf sur cela. Mais très souvent dans ce genre demande on passe à coté d'autre problématique qui ont pour conséquence que les performances souhaitées ne sont pas atteintes. Quel est le niveau en Python ou Java du développeur ? Est-ce que le développeur devra apprendre le langage durant ce projet ? Est-ce que le développeur aura tout son temps pour optimiser la solution ou est-ce que le projet à une dead-line ?

Avec tous ces éléments, il sera possible d'apporter des réponses qui orienteront dans la bonne direction.

Cordialement
Emmanuel

[autousto]

Je vous remercie pour vos réponses.

Pour information le fichier XML qui prend 5h est un fichier de plus de 1 million de lignes et le traitement comprend la lecture, la mise en forme et l’écriture sous forme de fichier .xls (puisque le but de l'outils et récupérer les données du fichier xml et les mettre dans un fichier xls).

Actuellement c'est un code Matlab qui pose pas mal de problèmes a cause d'une surcharge d’espace mémoire Java au moment de la lecture.

En ce qui concerne le Hard aucune modification n'est possible malheureusement.

Pour l'outil actuellement c'est un outil que j'ai repris pour amélioration, et donc j'ai suivi l'algorithme de base, une optimisation du code me fera gagner peut être 2h mais c'est toujours pas suffisant et ça va prendre du temps, alors si je dois re-coder je préfère partir sur un autre langage plus puissant.

Ce qui concerne les développeurs moi je peux me remettre en python et un ami qui connais bien Java, on hésite encore sur quoi partir

Cordialement

[wiztricks]

Actuellement c'est un code Matlab qui pose pas mal de problèmes a cause d'une surcharge d’espace mémoire Java au moment de la lecture.

Il faudrait voir combien de RAM cela consomme.
Intuitivement, il faut pouvoir découper en N tranches le cycle (1) tout charger en mémoire (2) effectuer les traitements (3) produire les résultats.

Je n'irais pas jusqu'à dire que la question n'a pas de sens, par contre, elle relève beaucoup de piège.

La question n'a pas de sens car le temps de traitement dépend de la possibilité/capacité d'organiser les traitements pour utiliser au mieux les ressources CPU, Mémoire, IO disques disponibles.

C'est une question de conception, de "design" de la solution dans laquelle le choix du langage de programmation est peu structurante.

- W

[Drawingrom]

A vue de nez je dirais que votre programme matlab charge tout le document xml en mémoire avant de le transformer. On va dire que c'est l'approche dom, c'est très pratique quand on veut naviguer dans les noeuds du document.

L'autre approche qui est plus appropriée dans votre cas est la lecture évènementielle / sax : on parcourt le document, chaque changement de noeud lève un event et on traite ainsi le document petit à petit.

Etape 1 : chercher un moyen de faire un parsing sax en matlab sans conserver le document complet en mémoire
Etape 2 : si 1 ne fonctionne pas, recoder. Ce sera vos compétences dans Java ou Python et l'intégration avec le reste de votre appli qui vous dicterons le choix car cela devrait avoir peu d'incidence sur la performance du parsing.

[tyrtamos]

Bonjour,

Je ne connais pas bien ce sujet, mais je crois qu'il existe une autre solution pour accélérer: utiliser les fonctionnalités XML (sax et dom) de la bibliothèque graphique PyQt4 (je suppose qu'elles existent encore sous PyQt5).

L'avantage serait:
- écrire facilement la logique d'ensemble en Python
- et faire appel aux fonctions XML rapides, puisqu'écrites en C++

Bien que ce soit une bibliothèque graphique, on peut utiliser ses fonctionnalités sans graphique en console si on le souhaite.

Ce qui n'empêche pas, bien entendu, les différentes analyses proposées dans les messages précédents.

[wiztricks]

Salut,

Python, Java et Qt sont des frameworks assez complets pour inclure des librairies XML qui sachent faire du DOM ou du SAX. Ils sont aussi assez ouverts pour permettre l'utilisation de librairies externes (comme libxml2) si nécessaire cote fonctionnalités ou performances.

Comme le programme existant ne fait pas que "lire" un fichier XML, si tant est que passer de DOM a SAX soit un élément de la solution, changer de "framework", c'est ré-écrire tout le programme !

SAX permettrait de lisser la charge cote "mémoire" de la phase de lecture mais un fichier XML peut être beaucoup plus complique a parser qu'un fichier CSV.

Comme le PO n'a pas donne beaucoup de détails sur la structure de son fichier XML difficile de savoir...

De plus passer de DOM a SAX pour parser les gros fichiers XML est une piste qui se trouve assez vite des qu'on cherche un peu... si le PO se pose éventuellement la question de changer de framework, on peut espérer qu'il a déjà explore cette piste (quoi que...).

- W

[autousto]

Dans Mtlab on a pas le Sax et Dome. on a d'autre fonctions pour parser les fichiers XML.

Ce qui concerne le choix de la librairie, bah vu que j'ai des problèmes de mémoire je vais pas m'amuser a charger un fichier de 40M comme c'est déjà le cas sur Matlab.

Donc effectivement je vais utiliser Sax, et traiter le document par partie.

Je vous remercie pour vos réponses.

Ps: wiztricks le [(quoi que...) && (la question n'a pas trop de sens)] n'aide pas trop pour apporter une réponse a la question.

[Jerome Briot]

Dans Mtlab on a pas le Sax et Dome

Première ligne de la documentation de la fonction xlsread de MATLAB :

Read XML document and return Document Object Model node

Sinon pour SAX, MATLAB est normalement fourni avec une version Java de Xerces (xercesImpl.jar) dans le sous-dossier /java/javaext du dossier d'installation de MATLAB.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
>> import org.apache.xerces.parsers.SAXParser
>> sax = SAXParser()
 
sax =
 
org.apache.xerces.parsers.SAXParser@3ed024df
 
>> methods(sax)
 
Methods for class org.apache.xerces.parsers.SAXParser:
 
SAXParser                 endElement                getEntityResolver         separator                 startDTD                  
any                       endExternalSubset         getErrorHandler           setContentHandler         startDocument             
attributeDecl             endGeneralEntity          getFeature                setDTDContentModelSource  startElement              
characters                endGroup                  getProperty               setDTDHandler             startExternalSubset       
comment                   endParameterEntity        hashCode                  setDTDSource              startGeneralEntity        
doctypeDecl               equals                    ignorableWhitespace       setDocumentHandler        startGroup                
element                   externalEntityDecl        ignoredCharacters         setDocumentSource         startParameterEntity      
elementDecl               getAttributePSVI          internalEntityDecl        setEntityResolver         textDecl                  
empty                     getAttributePSVIByName    notationDecl              setErrorHandler           toString                  
emptyElement              getClass                  notify                    setFeature                unparsedEntityDecl        
endAttlist                getContentHandler         notifyAll                 setLocale                 wait                      
endCDATA                  getDTDContentModelSource  occurrence                setProperty               xmlDecl                   
endConditional            getDTDHandler             parse                     startAttlist              
endContentModel           getDTDSource              pcdata                    startCDATA                
endDTD                    getDocumentSource         processingInstruction     startConditional          
endDocument               getElementPSVI            reset                     startContentModel

Après je ne connais ni Xerces, ni SAX, je ne peux donc pas me prononcer plus...

[ZZelle]

Pour les gros XML, il faut éviter SAX/DOM qui charge tout le document XML et préférer des solutions comme StAX (existe en java, sous python je sais pas) qui streame le document XML de balise en balise ...

Avec StAX sous java, j'arrive sans problème à parcourir des shapefiles (fichiers "GPS" en XML) de 5Go en moins de 5 minutes.