Textdateien zeilenweise einlesen

[mschnell]

irgendwann muss man die sowieso ins File schreiben, also warum nicht gleich dann wenn's passiert?

Wenn man 100-mal hintereinander schreibt (z.B.

Code: Alles auswählen

for i := 1 to 100 do begin
  klasse.strings[i] := inttostr(i);
end;
klasse.free;

Und die Datei ist 100 000 Zeilen lang dann dauert das direkte schreiben (was jedes Mal knapp 100 000 Zeilen auf der Platte lesen und schreiben muss) ungefähr 100 mal so lange wie ein gecacheter Zugriff, der erst bei free irgendwas auf die Platte schreibt.

-Michael

[Christian]

Das lässt sich ja abfangen ... ich halt es trotzdem für sinnvoll es gleich auf die platte zu schreiben z.b. wenn innerhalb der nächsten 100ms nichts mehr kommt wirds geschrieben.

[theo]

@mschnell: Ja, obwohl ich mir nicht ganz sicher bin, ob das Betriebssystem da evtl. auch noch was optimiert.
Wie würde denn dein Cache aussehen? Der braucht wahrscheinlich auch wieder Memory, und das wollten wir doch gerade nicht.
Wie schon gesagt, glaube ich, dass in dem meisten Fällen für so einen Zweck ge-addet wird. Das müsste schnell sein.
Für das was du in deinem Beispiel machst, wäre die TFileStringList natürlich nicht optimal. Auch nicht für sortieren und sowas.
Aber für Add und Get könnte man sie schon ordentlich optimieren.

[pluto]

dann müsst ihr gleich ein DB nehmen. die TStringlist sollte nur kleine mengen an Daten speichern wobei ich weiß hier auch wieder keine Werte was klein heißt.... könnte mir vorstellen das eine 2MB Große Datei schon Probleme machen könnte.

[theo]

Es spricht ja keiner von TStringList, sonder von einer Klasse, die ein ähnliches Interface hat, aber direkt auf Files arbeitet und nicht den ganzen Krempel ins Memory lädt.

[mschnell]

Wie würde denn dein Cache aussehen?

Ich stelle mir den Cashe als eine TStringlist vor, in der bis zu MaxCachedLines (als Property von TFileStrinList konfigurierbar) Zeilen gehalten werden. Ein Integer DynArray hält dann die Zuordnung "String in CashStringList" -> "Zeile in der Datei". Auf Anforderung (TFieStringList.Flush) oder wenn der Cache zu voll wird, werden alle oder einige der Strings in die Datei geschrieben. Viele auf einmal ist sehr viel effektiver, da ein Austauschen einer Zeile in der Datei wegen der unterschiedlichen Zeilenlängen ja nicht geht. Die Datei muss also völlig umgemodelt werden. Die optimale Methode dazu zu finden ist nicht so einfach. Man muss (wenn z.b. eine Zeile bei 1/3 und eine bei 2/3 einer Riesen-Datei jeweils ein Byte größer als vorher gespeichert werden soll) vermutlich Teile der Hauptdatei auf Hilfsdateien auslagern oder ähnliches.

-Michael

[theo]

Wie gesagt, ich glaube nicht so richtig an den Cache.
Das kann ganz schön kompliziert werden.
Wie willst du denn verschiedene Aktionen an verschiedenen Stellen cachen und v.a. nachher in "einem Rutsch" ausführen?
Beispiel:

Code: Alles auswählen

FileStrings[12]:='test';
FileStrings.Delete(15)
FileStrings[10006]:='hallo';
FileStrings.Add('test');
FileStrings[FileStrings.Count-1]:='test test';

Da nützt dir der Cache imho nix, du musst trotzdem x-mal umkopieren.
Dein Beispiel oben lässt sich auch vom Benutzer der Klasse optimieren, ohne dass die Klasse selber cached:

Code: Alles auswählen

for i := 1 to 100 do begin
  tempstringlist.add(inttostr(i));
end; 
FileStrings[1]:=tempstringlist.text; //in "einem Rutsch" eingefügt.

Hilfsdateien gefallen mir auch nicht. Das geht auch mit einer Datei.
Blockweise umkopieren. Eine Methode für Wachsen, eine für Schrumpfen.

[Christian]

Is ja auch alles quatsch Dateizugriffe cacht das Betriebssystem und da sollte man das auch belassen.

[pluto]

Naja, wenn FileStrings ein array währe, währe es kein Problem.

Kann man eigentlich eine Doppelt Verkette Liste irgendiw sinvoll mit einem Array verbinden ? also sprich die Speicher Stelle berechnen ?
(ich glaube erher nicht).

Was du machen könntest währe z.b. einfach häufe suchanfragen zu speichern z.b. 10 Stück. Dann schaust du in dieser Liste zu erst nach ob es den Eintrag schon gibt.... Wie machen das eigentlich DB'S?

[theo]

Naja, wenn FileStrings ein array währe,

... dann wäre es eine TStringList

[mschnell]

Is ja auch alles quatsch Dateizugriffe cacht das Betriebssystem und da sollte man das auch belassen.

Denk doch bitte 'mal nach !

Um eine Zeile von 10 Byte auf 11 Byte zu ändern muss fast die ganze 1 Gigabyte große Datei kopiert werden, weil ja in Textdateien keine Lücken erlaubt sind.

Um 1000 Zeile zu ändern, die vorher in einer Stringlist gecached worden sind braucht die ganze Datei auch nur einmal kopiert werden. Da hilft der Betriebssystem-Cache ach nicht viel. Wohl aber eine (aufwändige) Verwaltung der geänderten Zeilen.

-Michael

[Christian]

Na toll um diesen fall zu vermeiden kannst eh nur die ganze Datei im Speicher halten ergo TStringList nehmen, wer denkt denn hier nicht nach ? Und wo hast du schon mal Gigabytegrosse Textdateien gesehn ? Ich denk das ist Humbug.

[theo]

Das sehe ich auch wie Christian. Die Klasse sollte nur einen fixen Buffer verwenden, um etwas schneller lesen und schreiben zu können.
Aber eine beliebig anwachsende Stringlist macht das Ganze zwecklos.

[mschnell]

Na toll um diesen fall zu vermeiden kannst eh nur die ganze Datei im Speicher halten ergo TStringList nehmen, wer denkt denn hier nicht nach ?

Sinn macht TFileStringList sowieso nur bei Riesen-Dateien. Und da ist es absolut sinnvoll, die Änderungen im RAM zu halten und gesammelt in die Datei zu schreiben.

Mit viel RAM wird's natürlich besser. Dann nimmt man aber besser eine TStringList.

Und wo hast du schon mal Gigabytegrosse Textdateien gesehn ? Ich denk das ist Humbug.

Wie schon öfters gesagt, für nicht allzu große Textdateien macht das ganze keinen Sinn, da nimmt man natürlich TStringList. Das ist natürlich auch der Grund, warum es noch keiner programmiert hat.

-Michael

[Christian]

Also bei 5-50 mb Datein macht das schon sinn.