Le texte d'un livre est-il un gros contenu ?

Bonjour,
je travaille actuellement sur une appli. pour m'aider à taper des documents scientifiques et/ou des tutos.
Il faut donc que j'analyse du texte qui aura été tapé par l'utilisateur dans un fichier de type TEXT.

Je me pose la question de savoir comment traiter ce texte qui ressemble un peu à du Restructured Text. J'ai deux possibilités :

1. Créer une liste Python où je stocke les informations relatives au texte (comme par exemple les mises en forme).
2. Utiliser un flux qui analyse le fichier pour en créer un 2nd dans lequel je stocke les infos dans un format proche de xml, lequel fichier sera ensuite lu suivant d'autres flux pour des exports aux formats HTML, PDF via LaTeX, entre autres choses.

La 1ère méthode est vite mise en place mais la 2nde me parait plus sure mais inutile si la réponse à ma question de départ est non.

Quelqu'un aurait-il une suggestion (même si ma question est vague, peut-être que certains d'entre vous ont une expérience pouvant m'aider) ?

Bonsoir,
Je n'ai pas trop compris la question de départ: est-ce qu'il s'agit du volume des textes à traiter?
Pour le reste, convertir le fichier en XML (a défaut de le générer directement en XML à partir de l'éditeur) permet 'potentiellement' de le transformer dans tous les autres formats avec le convertisseur ad hoc - qui existe sans doute déjà.
Reste à comparer 1 a 2... Autrement dit quitte à analyser le texte pour connaître des informations sur sa structure pour quoi en profiter pour générer la version XML.
-W

Pas sûr que je réponde bien à la question aussi.

Si l'on part du principe :

Un mot en moyenne contient 8 lettres
Une ligne, en moyenne : 15 mots
Une page : 40 lignes
Un livre : 500 pages

Cela fais : 2 700 000 caractères (en comptant 1 espace de plus par mot) soit environ 2,5Mo

Même en multipliant toutes ces valeurs par 2, ce qui me paraît très large, on arrive à environ 40Mo.

Vu la taille mémoire des PC actuellement, je pense que tu peux traiter ça en mémoire sans problème.

Réponse convaincante.

Merci.

Au nombre de mots, il faut ajouter nombre de méta données qui ne sont pas nécessairement négligeables en entrée comme en sortie (surtout si on XMLIfie)

En plus rien n'indique que les traitements à effectuer sur le bouquin demande à ce qu'il soit complètement en mémoire.

Si on XMLifie (oops) le contenu, les unités d'informations titres, paragraphes, ... à conserver en mémoire sont relativement petits et une lecture/écriture au fil de l'eau est possible.

Fait de façon bestiale, lire 40Mo, puis les parcourir recopiant ces 40Mo dans un espace équivalent en remplaçant des tags par d'autres tags et écrire le résultat... donne un temps de calcul relativement petit (copie de mémoire à mémoire) par rapport aux temps de lecture/écriture disques.
En procédant ainsi impossible de paralléliser lectures et écritures: la durée de traitement total double.

Ensuite on pourra vouloir lancer plusieurs conversions en parallèle... La le gag sera qu'on va peut être utiliser trop de mémoire et constater des dégradations de performances importantes car...
L'OS a bout de mémoire physique va récupérer de la mémoire: comme le contenu du bouquin en entrée comme en sortie est accédé séquentiellement, ses pages iront dans le fichier de pagination et on va encore multiplier par 2 la durée à cause des IO disques: écriture de 40Mo dans le fichier de pagination, puis relecture et écriture dans le fichier de sortie.
Note: on peut éviter cela en mmappant le fichier en mémoire.

Trouvez vous toujours cela génial?
- W

wiztricks, j'ai décidé de passer à un traitement ligne par ligne de mes fichiers même si je ne suis pas totalement convaincu de l'utilité malgré tes arguments. Je doute d'autant plus que je me suis souvenu que David Mertz, l'auteur de "Text Processing in Python", indique qu'il n'a jamais eu besoin pour ces livres de faire un traitement ligne par ligne des fichiers sources.

Citation:

---

Envoyé par rambc

wiztricks, j'ai décidé de passer à un traitement ligne par ligne de mes fichiers même si je ne suis pas totalement convaincu de l'utilité malgré tes arguments. Je doute d'autant plus que je me suis souvenu que David Mertz, l'auteur de "Text Processing in Python", indique qu'il n'a jamais eu besoin pour ces livres de faire un traitement ligne par ligne des fichiers sources.

---

C'est flatteur mais... ligne par ligne, hu?!
Tu pourrais mapper le fichier en entrée avec mmap et le traiter comme si c'était un gros buffer: l'OS gèrera la mémoire mieux que toi... il ne devrait pas y avoir d'impact côté fichiers de pagination - c'est le fichier d'entrée - enfin à vérifier sur l'OS que tu utilises.
En sortie, il est en général préférable d'écrire plus gros que la ligne mais la nécessité de créer un buffer intermédiaire dépend de l'OS.
- W

Je comprend pas le soucis vraiment. Même avec des calculs vraiment pessimiste, on arrive à 100Mo ?

La plupart des machines actuelles ont un minimum 1Go de mémoire, si un peu plus ancienne 512Mo.

Ici, c'est a priori un traitement ponctuel d'un fichier, le programme ne restera pas en mémoire. Et même si au pire, ca swap, ca va gêner en quoi ?

Mais pourquoi pas, après tout, ca fais un exercice de style qui apporte son lot d'enseignement.

Je ne viens pas du C, donc quand je dis que je travaille ligne par ligne, je fais quelque chose comme :

Code:

---

1 2	for one Line myFile: ...

---

wiztricks, peux-tu donner un exemple de ce que tu dis car je n'arrive pas à te suivre avec tes dernières explications techniques ?

Citation:

---

Envoyé par DelphiManiac

Je comprend pas le soucis vraiment. Même avec des calculs vraiment pessimiste, on arrive à 100Mo ?

La plupart des machines actuelles ont un minimum 1Go de mémoire, si un peu plus ancienne 512Mo.

Ici, c'est a priori un traitement ponctuel d'un fichier, le programme ne restera pas en mémoire. Et même si au pire, ca swap, ca va gêner en quoi ?

---

swap ? :aie:

Citation:

---

Envoyé par DelphiManiac

Mais pourquoi pas, après tout, ca fais un exercice de style qui apporte son lot d'enseignement.

---

C'est vrai. Par contre la modification apporte quelques complications mais rien d'insurmontable.

De plus, le traitement du fichier va nécessiter l'appel à d'autres programmes pour fabriquer des graphiques, du coup cela me semble plus prudent.

Citation:

---

Envoyé par rambc

Je ne viens pas du C, donc quand je dis que je travaille ligne par ligne, je fais quelque chose comme :

Code:

---

1 2	for one Line myFile: ...

---

Peux-tu donner un exemple de ce que tu dis car je ne suis pas tes dernières explications techniques ?

---

Je t'ai donné un exemple sur l'autre thread !!

Nous venons d'assister à une collision de posts...
:bug:
En fait, je parlais des explications de wiztricks. C'est quoi cette histoire de map.

Citation:

---

Envoyé par rambc

Nous venons d'assister à une collision de posts...
:bug:
En fait, je parlais des explications de wiztricks. C'est quoi cette histoire de map.

---

La doc est là: http://docs.python.org/library/mmap.html
Et l'exemple donné est assez complet:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

import mmap   # write a simple example file with open("hello.txt", "w") as f: f.write("Hello Python!\n")   with open("hello.txt", "r+") as f: # memory-map the file, size 0 means whole file map = mmap.mmap(f.fileno(), 0) # read content via standard file methods print map.readline() # prints "Hello Python!" # read content via slice notation print map[:5] # prints "Hello" # update content using slice notation; # note that new content must have same size map[6:] = " world!\n" # ... and read again using standard file methods map.seek(0) print map.readline() # prints "Hello world!" # close the map map.close()

---

Avec mmap, le fichier est transformé en un tableau mémoire, mais on ne le lit pas même si on peut y accéder via des primitives de lecture de fichier (comme pour un StringIO) on peut aussi accéder aux 'octets' directement.

Ca fonctionne sur la base des internes de la gestion de mémoire virtuelle faite par l'OS.
Imaginons que nous lancions un programme tutu.exe lié à quelques DLL.
L'OS ne va pas lire le contenu de ces fichiers, au lieu de cela il va construire l'espace virtuel d'exécution du programme en disant toto.exe je le met entre telle et telle adresse, si on place la DLL truc entre telle et telle adresse, il faudra initialiser les vecteurs de transferts de cette façon.
En faisant cela il ne lit rien, il se contente de remplir un tableau qui indique au gestionnaire de défaut de pages où aller chercher 'physiquement' le contenu d'une page de l'espace virtuel auquel une page mémoire physique n'a pas été allouée.
Puis on initialise l'environnement et on démarre le programme (appel de main).
Note: Une DLL ne se charge pas toujours au même endroit: les vecteurs de transferts sont là pour que l'appel à une routine de la DLL puisse se faire.
Je n'ai pas mentionné l'espace libre... pour simplifier.

mmap est la primitive de l'OS qui permet de faire la même chose avec des fichiers 'normaux' - ni programmes, ni DLLs -.

Comme le fichier est balayé séquentiellement, l'OS pourra recopier le contenu du fichier dans l'espace virtuel mappé au fur et à mesure qu'on y accède. Il va le faire par pages de 8Ko voire plus s'il détecte le séquentiel.

S'il y a besoin de mémoire physique, il récupèrera les pages déjà traitées et se contente de jeter le contenu s'il n'est pas modifié ou de l'écrire dans le fichier de départ sinon.
Note: dans le cas le fichier est lu en mémoire, on modifie la page et s'il faut la récupérer, elle ira dans le fichier de swap/pagination.
-W

Citation:

---

Envoyé par DelphiManiac

Je comprend pas le soucis vraiment. Même avec des calculs vraiment pessimiste, on arrive à 100Mo ?

La plupart des machines actuelles ont un minimum 1Go de mémoire, si un peu plus ancienne 512Mo.

Ici, c'est a priori un traitement ponctuel d'un fichier, le programme ne restera pas en mémoire. Et même si au pire, ca swap, ca va gêner en quoi ?

Mais pourquoi pas, après tout, ca fais un exercice de style qui apporte son lot d'enseignement.

---

Exemple:
Avec 50Ko lus en 1ms, lire 100Mo va demander 5 s.
Les écrire va en demander au moins autant.
Donc la durée sera supérieure ou égale à 10 secondes.

Si le système est chargé, les pages transiteront par le fichier de pagination.
La durée sera alors de l'ordre de 20s.
Dans tous les cas, on immobilise 5 a 10% de la mémoire disponible pendant environ la moitié du temps.

Avec ce que je propose, la durée sera de l'ordre de 5 a 7 secondes et on immobilise que quelques Ko de mémoire physique.

La vrai question est de savoir si faire cela ainsi est beaucoup plus couteux (nb de lignes de code) que de le faire: tout lire/traiter/tout écrire

En C, définitivement oui:
- il faut gérer la mémoire à la main,
- les threads c'est compliqué,
- chaque appel système est galère à coder si on à pas le MAN ou des exemple sous la main.

En Python, honnêtement faire tout lire/traiter/tout écrire est plus simple mais mmap ou lire le fichier ligne par ligne pour le coller dans un buffer... Heu! c'est dommage de ne pas y penser mais ca reste humainement réalisable.
Après il y a la question des threads... Mais ca reste beaucoup moins compliqué que de le faire en C.
-W

Je n'ai pas tout saisi de tes explications mais les choses s'éclairent un peu. Je garde cela sous le coude au cas où. Merci.