Eviter une lecture fuite d'espace un document HTML avec HXT

Link to truncated version of example document Eviter une lecture fuite d'espace un document HTML avec HXT

J'essaie d'extraire le gros morceau de texte dans le dernier « pré », le processus, et le sortir. Aux fins de l'argumentation, disons que je veux appliquer

concatMap (unwords . take 62 . drop 11) . lines

au texte et le sortir.

Cela prend plus de 400M d'espace sur un document html 4M quand je le fais.

~~Le code que j'ai est assez simple, donc je ne l'inclue pas de peur de biaiser les réponses.~~
Voici une itération du code:

file = readDocument [(a_validate, v_0), (a_parse_html, v_1)] "Cache entry information.xhtml" 
text = fmap last $ runX $ 
    file >>> 
    deep (hasName "pre") /> 
    isText >>> 
-- changeText (unwords . take 62 . drop 11 . lines) >>> 
    getText

Je pense que le problème est que la façon dont je le fais, HXT essaie de garder tout le texte dans la mémoire comme il le lit. Selon this , il semble que HXT doit au moins lire tout le document, mais pas le stocker en mémoire.

Je vais essayer d'autres parseurs, HaXmL, étant le prochain.
N.B. I ont résolu le problème initial par traitement du fichier d'entrée sous forme de texte et la partie souhaitée délimitée par une "<pre>00000000:" et "</pre></body>\n</html>"

Source

2010-09-04 Alex R

essayer d'utiliser un ByteString du module Data.Bytestring.Lazy. La chaîne habituelle est optimisée pour la récursivité et se comporte plutôt mal en cas de grandes quantités de données. Vous pouvez également essayer de rendre vos fonctions plus strictes (par exemple, en utilisant seq) pour éviter des frais généraux importants dus à des thunk non évalués. Mais soyez prudent car cela peut rendre les choses encore plus vaines si elles sont appliquées incorrectement. PS: Il est toujours une bonne idée de fournir un bref exemple.

Source

2010-09-05 01:57:40 fuz

Voulez-vous dire ByteString? Je n'avais pas entendu parler de BitString jusqu'à ce que vous le mentionniez, et il semble que ce soit spécialisé quand je m'intéresse à des bits individuels. –

Oui ... Vous avez raison. – fuz

C'était la première chose que j'essayais, même avant de passer à HXT. Cela n'a pas aidé du tout. le problème était avec l'analyse réelle. –

L'analyseur HXT est-il un analyseur "en ligne"?

L'exemple que vous avez fonctionne bien pour avoir cordes, à condition que chaque ligne n'est pas pathologiquement longue:

unwords . take 62 . drop 11 . lines

Vous ne consomme 73 lignes d'entrée, 11 que vous déposez et 62 que vous opérez sur . Cependant, l'exemple est principalement sans rapport avec le traitement XML. Si l'analyseur HXT n'est pas un analyseur en ligne, vous devrez lire le fichier entier en mémoire avant de pouvoir utiliser l'opérateur sur les données de chaînes incorporées. J'ai peur de ne pas savoir si HXT est un analyseur en ligne, mais cela semble être le point crucial de votre problème.

Source

2010-09-05 12:19:34

Malheureusement, je ne suis pas sûr que HXT soit un analyseur en ligne ou non; J'ai essayé d'abord avec TagSoup, et cela a eu un problème similaire. J'ai vu des gens prétendant utiliser HXT sur des fichiers de taille GB, donc je suppose que c'est un analyseur en ligne. –

Je suppose que HXT n'est pas un analyseur en ligne (a.k.a. En règle générale, il est plus difficile de concevoir un analyseur en ligne qu'un analyseur en ligne, donc à moins d'indication contraire, je suppose qu'un parseur donné ne serait pas en streaming. Une recherche rapide accordé jusqu'à ce fil: http://stackoverflow.com/questions/2292729/with-haskell-how-do-i-process-large-volumes-of-xml Certainement hexpat serait bon candidat car il est construit sur un analyseur SAX, HaXML a également un support pour l'analyse en ligne (streaming) - vis l'importation du bon module. –

Eviter une lecture fuite d'espace un document HTML avec HXT

Répondre

Questions connexes