Haskell解析大xml文件与低内存



因此,我使用了几个Haskell XML库,包括hexpat和XML -enumerator。在阅读了Real World Haskell (http://book.realworldhaskell.org/read/io.html)中的IO章节后,我的印象是,如果我运行下面的代码,它将在我执行它时被垃圾收集。

然而,当我在一个大文件上运行它时,内存使用量随着它的运行而不断攀升。

runghc parse.hs bigfile.xml

我做错了什么?我的假设错了吗?映射/过滤器是否强制它评估所有内容?

import qualified Data.ByteString.Lazy as BSL
import qualified Data.ByteString.Lazy.UTF8 as U
import Prelude hiding (readFile)
import Text.XML.Expat.SAX 
import System.Environment (getArgs)
main :: IO ()
main = do
    args <- getArgs
    contents <- BSL.readFile (head args)
    -- putStrLn $ U.toString contents
    let events = parse defaultParseOptions contents 
    mapM_ print $ map getTMSId $ filter isEvent events
isEvent :: SAXEvent String String -> Bool 
isEvent (StartElement "event" as) = True
isEvent _ = False
getTMSId :: SAXEvent String String -> Maybe String
getTMSId (StartElement _ as) = lookup "TMSId" as

我的最终目标是用一个简单的类sax接口解析一个巨大的xml文件。我不希望必须了解整个结构才能得到发现"事件"的通知。

我是hexpat的维护者。这是一个bug,我现在已经在hexpat-0.19.8中修复了。谢谢你提醒我这件事。

这个bug是ghc-7.2.1上的新bug,它与一个交互有关,我没有预料到绑定到一个三元组的where子句和unsafePerformIO之间的交互,我需要使与C代码的交互在Haskell中显得纯粹。

这似乎是hexpat的一个问题。运行经过优化的编译程序,并且只针对length这样的简单任务,会导致线性内存使用。

查看hexpat,我认为存在过多的缓存(参见parseG函数)。我建议联系外籍维护人员并询问这是否是预期的行为。无论如何,它都应该在haddocks中提到,但是在库文档中,资源消耗似乎经常被忽略。

相关内容

  • 没有找到相关文章

最新更新