7

我想了解为什么这个简单的解析器会耗尽大文件的内存。我真的不知道我在做什么错。

import Data.Attoparsec.ByteString.Char8
import qualified Data.Attoparsec.ByteString.Lazy as Lazy
import System.Environment
import qualified Data.ByteString.Lazy as B
import Control.Applicative

parseLine :: Parser String
parseLine = manyTill' anyChar (endOfLine <|> endOfInput)

parseAll :: Parser [Int]
parseAll = manyTill' 
        (parseLine >> (return 0)) -- discarding what's been read
        endOfInput

main :: IO()
main = do 
        [fn] <- getArgs
        text <- B.readFile fn

        case Lazy.parse parseAll text of
                Lazy.Fail _ _ _ -> putStrLn "bad"
                Lazy.Done _ _ -> putStrLn "ok"

我正在运行程序：

 runhaskell.exe test.hs x.log

输出：

test.hs: Out of memory

x.log 的大小约为 500MB。我的机器有 16GB 的 RAM。

4

2 回答 2

4

如果您查看attoparsec 的文档，您会注意到有一个类似的示例，并附有以下注释：

注意重叠的解析器anyChar和string "-->". 虽然这会起作用，但它不是很有效，因为它会导致很多回溯。

anyChar使用拒绝接受的字符的替代方法endOfLine应该可以解决问题。例如

satisfy (\c -> c `notElem` ['\n', '\r'])
于 2016-12-29T14:22:41.810 回答
3

我对 Attoparsec 不太熟悉，但我认为您可能很难单独使用它来解析常量内存中的大文件。如果您将顶级解析器替换parseAll为：

parseAll :: Parser ()
parseAll = skipMany anyChar

并对其进行分析，您会发现内存使用量仍在无限制地增长。（当我将您的代码转换为使用带有 strictByteString的增量阅读时，它没有任何区别。）

我相信问题是这样的：因为 Attoparsec 会自动回溯，所以必须准备好parseAll（你的版本或我的版本——没关系）才能像这样使用：

(parseAll <* somethingThatDoesntMatch) <|> parseDifferently

如果parseAll已经解析了 50 万行并到达末尾，somethingThatDoesntMatch将导致它一直回溯到开头，然后用parseDifferently. 因此，在解析完全完成之前，无法释放回溯的元信息和 ByteStrings 本身。

现在，您的解析器（以及我上面的示例）“显然”不需要以这种方式回溯，但 Attoparsec 不会推断出这一点。

我可以想到几种方法来进行：

  1. 如果您解析的是兆字节而不是千兆字节，请考虑使用 Parsec，它只会在明确时回溯（例如，使用try）。
  2. 使用手工制作的非回溯解析器将您的日志文件分解为行（或行块），并在每一行/块上运行您的 Attoparsec 解析器以完成。
于 2016-12-29T19:22:59.557 回答