Haskell ByteStrings - endend mit großen Datei bis in den Speicher geladen

Question

Grüße,

Ich versuche zu verstehen, warum ich die gesamte Datei in den Speicher mit dem folgenden Programm geladen zu sehen bin, aber wenn Sie die Zeile aus kommentieren unten "(***)" dann läuft das Programm in konstantem (ungefähr 1,5M) Raum.

EDIT: Die Datei ist etwa 660 MB, das Feld in Spalte 26 ist eine Datumszeichenfolge wie '2009-10-01', und es gibt eine Million Zeilen. Der Prozess verwendet etwa 810 MB bis zum Zeitpunkt der 'getLine'

Habe ich recht in der Annahme, es ist mit der Aufspaltung der Zeichenfolge mit 'Split' verbunden, und dass irgendwie die zugrunde liegende ByteString, die aus der Datei gelesen wurde Wird kein Müll gesammelt, weil er immer noch referenziert wird? Aber wenn, dann dachte ich, BS.copy würde das umgehen. Irgendwelche Ideen, wie man die Berechnung erzwingt - ich kann nicht scheinen, Seq 'in den richtigen Platz zu bekommen, um einen Effekt zu haben.

(NB die Quelldatei durch Tabulatoren getrennte Linien)

Vielen Dank im Voraus,

Kevin

module Main where 

import System.IO 
import qualified Data.ByteString.Lazy.Char8 as BS 
import Control.Monad 


type Record = BS.ByteString 

importRecords :: String -> IO [Record] 
importRecords filename = do 
    liftM (map importRecord.BS.lines) (BS.readFile filename) 

importRecord :: BS.ByteString -> Record 
importRecord txt = r 
    where 
    r = getField 26 
    getField f = BS.copy $ ((BS.split '\t' txt) !! f) 

loopInput :: [Record] -> IO() 
loopInput jrs = do 
    putStrLn $ "Done" ++ (show $ last jrs) 
    hFlush stdout 
    x <- getLine 
    return() 

    -- (***) 
    loopInput jrs 

main = do 
    jrs <- importRecords "c:\\downloads\\lcg1m.txt" 
    loopInput jrs 

Answer 1

Ihr Anruf zu last die Liste zwingt, jrs. Um das herauszufinden, muss es durch die gesamte Datei laufen, die für jeden Eintrag in jrs Thunks aufbaut. Da Sie nicht jedes Element in jrs (außer dem letzten) bewerten, hängen diese Thunks mit Verweisen auf den Byte-String, so dass diese im Speicher bleiben müssen.

Die Lösung besteht darin, die Auswertung dieser Thunks zu erzwingen. Weil wir über Raum reden das erste, was ich tat, war eigentlich Ihre Daten in einem kleineren Format zu speichern:

type Year = Word16 
type Month = Word8 
type Day = Word8 
data Record = Rec {-# UNPACK #-} !Year {-# UNPACK #-} !Month {-# UNPACK #-} !Day 
     deriving (Eq, Ord, Show, Read) 

Dies reduziert das hässlich 10 Byte Bytestring (+ Overhead von ~ 16 Bytes von Strukturinformationen) auf rund 8 Bytes.

importRecord hat jetzt toRecord r rufen die richtige Art zu erhalten:

toRecord :: BS.ByteString -> Record 
toRecord bs = 
    case BS.splitWith (== '-') bs of 
      (y:m:d:[]) -> Rec (rup y) (rup m) (rup d) 
      _ -> Rec 0 0 0 

rup :: (Read a) => BS.ByteString -> a 
rup = read . BS.unpack 

Wir brauchen Daten evalute wenn wir ByteString-Record konvertieren, können so verwenden Sie die parallel Paket und definieren eine NFData Instanz von .

instance NFData Record where 
    rnf (Rec y m d) = y `seq` m `seq` d `seq`() 

Jetzt sind wir bereit zu gehen, ich modifizierte Haupt evalList zu verwenden, wodurch die gesamte Liste zu zwingen, bevor Sie Ihre Funktion, die die letzte will:

main = do 
    jrs <- importRecords "./tabLines" 
    let jrs' = using jrs (evalList rdeepseq) 
    loopInput jrs' 

Und wir können den Haufen Profil sehen sieht gut aus (und stimmt überein, verwendet das Programm sehr wenig Speicher).

Tut mir leid, dass andere falsche Antwort irreführend - ich war auf der Tatsache, dass süchtig inkrementelle Verarbeitung es fixiert und wußte nicht wirklich die Thunks wirklich um hing, nicht sicher, warum glitt mein Gehirn über Das. Obwohl ich dem Kern zutraue, sollten Sie diese Informationen inkrementell verarbeiten, sodass all diese Antworten strittig sind.

Bitte beachten Sie, dass der riesige Byte-String nicht in den vorherigen Heap-Profilen angezeigt wurde, die ich gepostet habe, da Fremdzuweisungen (einschließlich ByteString) nicht vom Heap-Profiler verfolgt werden.

Answer 2

Es scheint zwei Fragen hier zu sein:

• warum die Speicherauslastung abhängig von der Anwesenheit oder Abwesenheit der Linie (***);
• Warum ist die Speicherauslastung mit (***) etwa 800 MB statt etwa 40 MB.

Ich weiß nicht wirklich, was ich über die erste sagen soll, die TomMD nicht schon gesagt hat; Innerhalb der loopInput-Schleife kann jrs nie freigegeben werden, da es als Argument für den rekursiven Aufruf von loopInput benötigt wird. (Sie wissen, dass return() nichts tut, wenn (***) vorhanden ist, nicht wahr?)

Wie für die zweite Frage, ich denke, Sie haben Recht, dass die Eingabe ByteString nicht Müll gesammelt wird. Der Grund ist, dass Sie nie die Elemente Ihrer Liste jrs neben der letzten auswerten, so dass sie immer noch Verweise auf den ursprünglichen ByteString enthalten (obwohl sie das Format BS.copy ... haben). Ich würde denken, dass das Ersetzen von show $ last jrs durch show jrs Ihre Gedächtnisnutzung verringern würde; macht es? Alternativ können Sie eine strengere Karte versuchen, wie

map' f []  = [] 
map' f (x:xs) = ((:) $! (f $! x)) (map' f xs) 

Ersetzen Sie die map in importRecords mit map' und sehen, ob die Speicherauslastung reduziert.