EOutOfMemory - Zu wenig Arbeitsspeicher

[DelphiFan2008]

Hallo Delphi-Gemeinde,

ich schreibe gerade eine kleine Applikation mit der ich ein aus einer Datenbank erzeugter Textdatei Datensätze filtern möchte. Das Textfile ist mächtig groß - 1.025.250 kByte - sollte unter Win7 64bit und einem recht gut ausgestatteten Rechner mit 16GB unproblematisch sein.

Gelesen werden die Daten an einem Stück in ein array of Byte

Delphi-Quellcode:

    
    FS := TFileStream.Create( Filename,fmOpenRead or fmShareDenyWrite );
    try
      l := FS.Size;
      if( l>0 )then
      begin
        SetLength( ar,l );
        FS.Read( Pointer( ar )^,l );
      end;
    finally
       FS.Free;
    end;

Danach läuft ein Algorithmus der die mit $0A getrennten Datensätze analysiert und die mit $09 getrennten Einträge filtert. Die derzeitige Anzahl der Datensätze beläuft sich auf 8.503.400, d.h. ca.120 Byte pro Datensatz.

Aus dem Datensatz werden die einzelnen Einträge - im Wesentlichen Strings und ein paar Zahlen, welche vorher von String in Integer bzw. Double gewandelt werden - gefiltert und in einem Rekord gespeichert.

Delphi-Quellcode:

type
  PDataSet = ^TDataSet;
  TDataSet = record
    Str1        : String;      // # 0
    Str2        : String;      // # 1
    Int1        : Integer;

Die mit P := New( PDataSet ) erzeugten Datensätze werden dann in einer TList mit TList.Add(...) hinzugefügt und zum Schluß auf Platte abgelegt.

Das ganze funktioniert - jedoch nur wenn die Anzahl der Datensätze limitiert bzw. ein Filter dafür sorgt, dass nicht alle Datensätze hinzugefügt werden. Ansonsten tritt ein EOutOfMemory Fehler auf. Im Grunde ist es kein "so schwerwiegendes" Problem, da ich nicht alle Datensätze benötige (gefiltert). Da ich jedoch die Grenze der Einträge nicht kenne macht mich das Ganze etwas nervös.

Ein Probelauf mit Filter und damit erzeugten 3.356.000 Datensätzen funktioniert problemlos.

Gibt es eine Grenze für Einträge in der TList, nach meinem Versuch sind das kleiner 1GB.

Weis jemand Rat?

Gruß DelphiFan2008

[Bernhard Geyer]

Du hast eine 32-Bit Anwendung. Diese kann von den 16 GB eh nur selbst 2 GB in eigenregie verwalten. Da in diesen 2 GB auch noch solche "Nebensächlichkeiten" wie DLL's geladen werden sind das weniger. Das Hauptproblem ist aber das du 1 GB als durchgehenden Adressraum anforderst was du bei einer 32-Bit Anwendung fast nie zur verfügung hast.

Lösung: Lese die Datei in kleineren Happen (z. B. 16 kB) ein und Analysiere diese.

[jaenicke]

Zitat von DelphiFan2008:

ich schreibe gerade eine kleine Applikation mit der ich ein aus einer Datenbank erzeugter Textdatei Datensätze filtern möchte.

Auf die Datenbank hast du keinen Zugriff? Das hört sich sonst erst einmal wenig sinnvoll ein, die Daten in eine Textdatei zu exportieren und dann zu parsen, wenn du auch direkt an die DB herankämst...

[Luckie]

Zitat von Bernhard Geyer:

Diese kann von den 16 GB eh nur selbst 2 GB in eigenregie verwalten. Da in diesen 2 GB auch noch solche "Nebensächlichkeiten" wie DLL's geladen werden sind das weniger.

Stimmt nicht ganz. Die System DLLs werden in den 2 GB Adressraum geladen auf den der Prozess keinen (Schreib)Zugriff hat.

[Bernhard Geyer]

Zitat von Luckie:

Stimmt nicht ganz. Die System DLLs werden in den 2 GB Adressraum geladen auf den der Prozess keinen (Schreib)Zugriff hat.

Hab je extra nicht von System-DLLs geschrieben. Die ganzen "Systemerweiterungs"-DLLs wie Grafikkartentreiber, Virenscanner, ... welche schön verteilt im User-2GB-Adressraum sich verteilen bereiten die Probleme.

[Luckie]

Das höre ich jetzt zum ersten mal. Bist du dir da sicher? Hast du eine Quelle?^

[jaenicke]

Du kannst in VMMap sehen was wo im Speicher geladen ist:
http://technet.microsoft.com/en-us/s.../dd535533.aspx

[Luckie]

Tatsächlich. Wieder was gelernt.

[jaenicke]

Das war übrigens auch das Problem mit der BDE. Dort gab es die Einstellung SharedMemLocation. An der Stelle wurde dann die DLL geladen. Schlecht nur, wenn an der Stelle dann schon etwas geladen war... dann kam Initialisierung fehlgeschlagen.