Eigenes Zeichen für Zeilenende bei ReadLN

[Perlsau]

Zitat von Luckie:

Er ist wohl der Meinung, dass eine StringListe für so große Dateien nicht geeignet wäre.

Vielleicht stimmt das ja auch:

Eben hatte ich einen Testdurchlauf gestartet mit einer ca. 285 MB großen Textdatei. Beim Versuch, diese Datei (nicht Zip einlesen, sondern vorher entpacken) direkt in eine Stringliste einzulesen, erhalte ich nach kurzer Zeit die Meldung, ich hätte zu wenig Arbeitsspeicher:
Exception der Klasse EOutOfMemory mit der Meldung 'Zu wenig Arbeitsspeicher' aufgetreten.
In meinem Rechner sind 4 GB Ram verbaut. Geöffnet sind ein Dateimanager, Seamonkey, Thunderbird und RadStudio 2009 nebst im Debug-Mode laufender Exe. Das kann's doch nicht sein

Delphi-Quellcode:

procedure TForm1.Button_TextClick(Sender: TObject);
Var
   Liste : TStrings;

begin
     IF NOT OpenDlg.Execute THEN Exit;
     Liste := TStringList.Create;

     Try
       Liste.LoadFromFile(OpenDlg.FileName);
     Finally
       Liste.Free;
     End;
end;

Lese ich dagegen die Textdatei via ReadLn ein und weise dabei jedesmal der Stringliste die eingelesene Zeile zu, komme ich auf 7.654.474 Zeilen, die sich am Ende in der Stringliste befinden. Das verstehe ich nicht: Beim direkten Einlesen ist der Speicher angeblich zu klein, beim Zuweisen über ReadLn paßt's dann wieder rein ...

Delphi-Quellcode:

procedure TForm1.Button_TextClick(Sender: TObject);
Var
   Liste : TStrings;
   f     : TextFile;
   Zeile : String;
begin
     IF NOT OpenDlg.Execute THEN Exit;
     Liste := TStringList.Create;
     AssignFile(f,OpenDlg.FileName);
     Reset(f);

     Try
       WHILE NOT EOF(f) DO
       BEGIN
         ReadLn(f,Zeile);
         Liste.Append(Zeile);
         Label_Anzahl.Caption := IntToStr(Liste.Count);
         Application.ProcessMessages;
       END;
     Finally
       Liste.Free;
       CloseFile(f);
       Label_Anzahl.Caption := Label_Anzahl.Caption + ' ' + Zeile;
     End;
end;

Es erfolgt keine Fehlermeldung, alle Zeilen der Datei wurden in die Stringliste übertragen. Wie kann es also sein, daß beim direkten Befüllen der Stringliste eine Meldung erscheint, der Arbeitsspeicher würde nicht ausreichen?

Eben erhalte ich die Mitteilung, daß die erste Procedure mit Liste.LoadFromFile, wenn sie mit XE2 kompiliert wurde, fehlerfrei arbeitet.

[Uwe Raabe]

Zitat von Perlsau:

In meinem Rechner sind 4 GB Ram verbaut. Geöffnet sind ein Dateimanager, Seamonkey, Thunderbird und RadStudio 2009 nebst im Debug-Mode laufender Exe. Das kann's doch nicht sein

Erstmal hat eine 32-Bit-Anwendung nur maximal 2GB Speicher zur Verfügung und dann getht TStringList.LoadFromFile da schon ziemlich verschwenderisch mit dem Speicher um. Die Datei hat knapp 300MB, die zunächst als TBytes geladen werden. Dann schlägt das Encoding zu, das da nochmal die doppelte Menge drauf legt (wegen Unicode) und die Zeichen in einem Character Array ablegt (sind dann schon fast 900MB). Das nachfolgende Erzeugen des Unicodestring (600MB) schlägt dann fehl, weil offenbar der Speichermanager nicht mehr mitspielt (VirtualAlloc schlägt fehl).

Als 64-Bit funktioniert es dann aber.

Man könnte jetzt natürlich TStringList ableiten, LoadFromStream überschreiben und für große Dateien effizienter implementieren.

[Perlsau]

Hallo Uwe, da hab ich wieder was dazugelernt Dafür danke ich dir

Zitat von Uwe Raabe:

Als 64-Bit funktioniert es dann aber.

Hab mir eben mal kurz Lazarus installiert, mit dem der TE ja offenbar arbeitet:

Das war ein Irrtum, ich hatte es in XP-64 gestestet:

Zitat:

Dort gibt es keine Fehlermeldung, wenn ich dieselbe Datei mit LoadFromFile in eine Stringlist lade, und das auf XP Pro 32. Ergo könnte er doch zumindest eine Stringlist verwenden, um seine 200 MB-Datei einzulesen. Da scheint Lazarus gegenüber Delphi was voraus zu haben ... Allerdings scheint Lazarus Probleme mit Unicode-Dateien zu haben ... Naja, sei's drum, ich will da jetzt nicht tiefer einsteigen in die Programmierung mit Lazarus.

Unter XP-32 taucht dieselbe Fehlermeldung auch unter Lazarus auf ...

Zitat von Uwe Raabe:

Man könnte jetzt natürlich TStringList ableiten, LoadFromStream überschreiben und für große Dateien effizienter implementieren.

Wer das kann? Mir wäre das zuviel an Aufwand ...

[jaenicke]

Zitat von Perlsau:

Zitat von Uwe Raabe:

Man könnte jetzt natürlich TStringList ableiten, LoadFromStream überschreiben und für große Dateien effizienter implementieren.

Wer das kann? Mir wäre das zuviel an Aufwand ...

Naja, für LoadFromFile im Grunde meine Unit zum Einlesen und intern noch das Arrayhandling verbessern, das wars schon. Also so viel ist das nicht.

[Ginko]

So ich habs mal mit dem Filestream gemacht. Das geht gar nicht, also von der Geschwindgkeit her ...
Bei einer Textdatei von 8Mb brauchte das ca 36s, mit ReadLn und angepassten TextBuffer hingegen nur ca 65ms.

Delphi-Quellcode:

var
  FileStrm1: TFileStream;
  Ch: Char;
  GesLength: Integer;
  Gesucht,Seite: String;
  StrList1: TStringList;
begin
  Gesucht:= ( UTF8Decode( Edit1.Text ) );

  StrList1:= TStringList.Create;
  FileStrm1:= TFileStream.Create('Textdatei.txt',fmOpenRead);
  try
    GesLength:= 0;

    while FileStrm1.Position < FileStrm1.Size do 
    begin
      Seite := '';
      while (FileStrm1.Read(Ch, 1) = 1) and ( Ch <> #12 ) do //Seite in String speichern
        Seite := Seite + Ch;
       
      ...
      {Textsuche und weitere Auswertung, Ergebnisse in Stringlist speichern...}
      ...    

      GesLength:= GesLength + SeitenLength + 1;
    end;

  finally
    FreeAndNil(StrList1);
    FreeAndNil(FileStrm1);
  end

Ich werde mir noch die Klasse von jaenicke ansehen. Danke für den Hinweis.

[hathor]

Wenn die Textstruktur erhalten bleiben soll, muss man es auch so einlesen:
- zeilenweise vom Zeilenanfang bis Zeilenende #13#10
- seitenweise bis zum 1. Auftreten von #12, dann vom 1.Zeichen nach #12 bis zum nächsten #12 usw.

Steuerzeichen:
0001100,0xc,12,FF=Form Feed - Setzt Cursor auf Zeilenvorschub einer vorangegangenen Zeile

[Sir Rufo]

Das ist auch nicht weiter verwunderlich schickst du doch den FileStream immer wieder an das Ende der Datei und dann zurück an die aktuelle Leseposition (FileStrm1.Size ).

Darum solltest du dir die Größe des Streams zwischenspeichern, dann sollte das erheblich schneller vonstatten gehen

Delphi-Quellcode:

var
  FileStrm1: TFileStream;
  LStreamSize : Int64; // lokale Variable
  Ch: Char;
  GesLength: Integer;
  Gesucht,Seite: String;
  StrList1: TStringList;
begin
  Gesucht:= ( UTF8Decode( Edit1.Text ) );

  StrList1:= TStringList.Create;
  FileStrm1:= TFileStream.Create('Textdatei.txt',fmOpenRead);
  try
    GesLength:= 0;

    // Stream-Size merken
    LStreamSize := FileStrm1.Size;

    // und damit prüfen
    while FileStrm1.Position < LStreamSize do 
    begin
      Seite := '';
      while (FileStrm1.Read(Ch, 1) = 1) and ( Ch <> #12 ) do //Seite in String speichern
        Seite := Seite + Ch;
       
      ...
      {Textsuche und weitere Auswertung, Ergebnisse in Stringlist speichern...}
      ...    

      GesLength:= GesLength + SeitenLength + 1;
    end;

  finally
    FreeAndNil(StrList1);
    FreeAndNil(FileStrm1);
  end

[Furtbichler]

Es wird 2x geprüft, ob noch Zeichen da sind, und zwar einmal beim Abfragen der Position und dann nochmal ob das Lesen eines Zeichens funktioniert hat. Das ist nicht schön.

Ich würde eine Funktion schreiben, die genau eine Seite liefert und True/False, ob noch weitere Seiten zu erwarten sind.

Delphi-Quellcode:

Function ReadOnePage (myFileStream : TStream; Var Page : String) : boolean;
Const 
  CharSize = SizeOf(Char);
Var
  Ch : Char;

Begin
  result := True;
  Page := '';
  While myFileStream.Read(Ch,CharSize) = CharSize do 
    if Ch=#12 then 
      exit 
    else 
      Page := Page + Ch;

  result := false;
End;

// Der eigentliche Aufruf ist dann ziemlich selbsterklärend
While ReadOnePage (myFileStream, Page) Do 
  ProcessPage(Page)

[Ginko]

@Furtbichler Danke für den Hinweis, allerdings konnte mit der Funktion keinen wesentlichen unterschied merken, auch ca 36s für die Suche von ca 2200 Wörtern.

Zitat von Sir Rufo:

Darum solltest du dir die Größe des Streams zwischenspeichern, dann sollte das erheblich schneller vonstatten gehen

Das werd ich mal noch versuchen Danke für die Antworten nochmal. Hab den Beitrag grad übersehen...