Problem mit writeln (Text erstellen)

[Klaus01]

.. ich möchte dann mal die Folgende Klassen TStreamWriter
und TStreamReader in den Raum werfen.

TStreamWriter.WriteLine
TStreamReader.ReadLine

Grüße
Klaus

[p80286]

Zu kurz geworfen,in D7 unbekannt,
wie wäre es mit TStringStream ?
aber da fehlt mir die Angabe der Datei aus der ich lesen will.

Gruß
K-H

[himitsu]

TStringStream + TFileStream




Text-Dateien haben auch ohne SetTextBuf schon einen komischen 128 Byte-Puffer.

Das paßt nichtmal im Geringsten zur ClusterSize der Partitionen oder zur SectorSize der Datenträger.

Beim Lesen ist ein Puffer OK, aber wozu beim Schreiben?
Die Daten gehen sowieso nochmal durch die WFC (Windows File Cache ... das Teil, welches den RAM voll macht) und dann nochmal durch verschiedenste Caches.

Wenn das Programm abstürtzt, sind diese Daten weg, was geade bei LogDateien etwas blöd ist, vorallem wenn man das Warum wissen will.

Delphi-Quellcode:

var
  F: TextFile;
  B: Byte;  // für LogDateien so klein wie möglich (0 ist leider nicht möglich) und ansonsten wäre es ein bissl größer nicht schlecht.
begin
  AssignFile(F, 'Text.dat', CP_UTF8);  // Ja, wir können jetzt sogar unicode, auch wenn die BOM nicht automatisch rein kommt.
  System.SetTextBuf(F, B);
  Rewrite(F);
  WriteLn(F, '123456');
  CloseFile(F);

[p80286]

Zitat von himitsu:

Wenn das Programm abstürtzt, sind diese Daten weg, was geade bei LogDateien etwas blöd ist, vorallem wenn man das Warum wissen will.

Genau das ist ja der Grund für mich da mal auf writeln zurück zu greifen.
Nach meinem Kenntnisstand wird der Buffer bei einem Closefile weggeschrieben, also seh ich da keine Gefahr des Datenverlustes (natürlich für jede Zeile das append,writeln,closefile)
Was den Buffer angeht und den Tstream vielleicht komm ich am WE mal dazu etwas zu Teste ob es da signifikante Geschwindigkeitsunterschiede gibt.

Gruß
K-H

[himitsu]

Zitat von p80286:

Genau das ist ja der Grund für mich da mal auf writeln zurück zu greifen.
Nach meinem Kenntnisstand wird der Buffer bei einem Closefile weggeschrieben,

Nein und genau deswegen.

Bei CloseFile landen die Daten auch nur in der WFC.
Also genauso wie bei den FileStreams, denn FileStream und das Pascal-Zeugs nutzen intern die selbe WinAPI, abgesehn von dem zusätzlichen Caching der TextFile.

Append tut erstmal das Ende der Datei einlesen um das vermeintliche Ende zu suchen.

Die alten Pascal-Funktionen sind also, in Bezug auf den Absturz des Programms eher im Nachteil.
- entwerder potentieller Datenverlust, bei geöffneten Dateien
- oder Overkill durch das ständige Öffnen und Schließen

Beim FileStream kann es offen bleiben und es kommt dennoch nichts weg, wenn das Programm abstürzt.


Wenn der ganze Computer verrekt, kann man durch entsprechende Optionen das Caching des FileStreams beeinflussen und auch da für ein sichereres Speichern sorgen, selbst wenn Windows verrekt.
Alternativ müstest du dir dafür ein eigenes AssingFile programmieren und die internen Open-/Closefunktionen ebenfalls durch eigene Versionen ersetzen und zusätzlich erstmal die Interna ergründen, da hierzu nichts in der OH drinsteht.
Beim FileStream, bzw. THandleStream+CreateFile kannst du über die OH und das MSDN alles direkt erfahren.

[p80286]

[QUOTE=himitsu;1172083]

Zitat von p80286:

Append tut erstmal das Ende der Datei einlesen um das vermeintliche Ende zu suchen.

Und das kostet, Faktor ca. 1000.
Bei der Gelegenheit hab ich mir die Auswirkungen von Settextbuf auf den Durchsatz angeschaut. sowohl das Schreiben ohne, als auch mit Buffsize=1 bzw Buffsize=8194 hatte keine signifikanten Auswirkungen.

Gruß
K-H

[Boyington]

Morgen Zusammen,
danke für eure Antworten, das Problem nun schon gelöst
Ich habe Rewrite(F); und CloseFile(F); einfach vergessen. Jetzt läuft das Programm einwandfrei.

Gruss
Lee