2011-11-09 32 views
6

Vì vậy, tôi đã chơi xung quanh với một số thư viện XML Haskell, bao gồm cả hexpat và xml-enumerator. Sau khi đọc chương IO trong thế giới thực Haskell (http://book.realworldhaskell.org/read/io.html) Tôi đã bị ấn tượng rằng nếu tôi chạy đoạn mã sau, nó sẽ là rác thu thập được khi tôi đi qua nó.Haskell phân tích cú pháp tệp xml lớn với bộ nhớ thấp

Tuy nhiên, khi tôi chạy trên một tệp lớn, mức sử dụng bộ nhớ tiếp tục tăng khi nó chạy.

runghc parse.hs bigfile.xml 

Tôi đang làm gì sai? Giả định của tôi có sai không? Bản đồ/bộ lọc có buộc nó đánh giá mọi thứ không?

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 

Mục tiêu cuối cùng của tôi là phân tích cú pháp tệp xml lớn với giao diện giống như sax đơn giản. Tôi không muốn phải nhận thức được toàn bộ cấu trúc để được thông báo rằng tôi đã tìm thấy một "sự kiện".

+1

Bạn cũng có được hành vi này khi biên dịch nó thay vì chạy nó trong chế độ diễn giải? – hammar

+0

Và đừng quên sử dụng tối ưu hóa (-O2) khi biên dịch. –

+0

Bạn có phải biên dịch và tối ưu hóa để làm cho nó thu thập rác không? Nếu vậy, tôi sẽ chắc chắn để thử điều đó trong tương lai –

Trả lời

8

Tôi là người duy trì hexpat. Đây là một lỗi mà tôi đã sửa trong hexpat-0.19.8. Cảm ơn vì đã thu hút sự chú ý của tôi.

Lỗi này là mới trên ghc-7.2.1 và nó liên quan đến tương tác mà tôi không mong đợi giữa mệnh đề where liên kết với triple và unsafePerformIO, mà tôi cần phải thực hiện tương tác với C mã xuất hiện thuần túy trong Haskell.

+0

Bây giờ đó là những gì tôi gọi là người bảo trì! Làm tốt lắm. –

3

Điều này có vẻ là vấn đề với hexpat. Chạy được biên dịch, với tối ưu hóa và chỉ cho một tác vụ đơn giản như length, dẫn đến sử dụng bộ nhớ tuyến tính.

Nhìn vào hexpat, tôi nghĩ có quá nhiều bộ nhớ đệm đang diễn ra (xem hàm parseG). Tôi đề nghị liên hệ với người bảo trì hexpat và hỏi xem đây có phải là hành vi được mong đợi hay không. Nó nên đã được đề cập trong haddocks một trong hai cách, nhưng tiêu thụ tài nguyên dường như bị bỏ qua quá thường xuyên trong tài liệu thư viện.

+0

Từ [một hồ sơ nhanh chóng đống] (http://i.stack.imgur.com/8mYdh.png), có vẻ như hầu hết nó đến từ rò rỉ ' (:) 'các hàm tạo. – hammar

+0

Rất vui được biết giả định của tôi không sai. Tôi đoán tôi sẽ tiếp tục làm rối tung các gói khác. Cảm ơn! –

Các vấn đề liên quan