TFileStream Strings saven kalppt nicht

[Flippo]

Hi,
also was ich brauche ist ein möglichst kompaktes und schnelles Verfahren um mehrere Wörter zu speichern und auszulesen, Vergleiche anzustellen usw.(Es werden aber wirklich sehr viele( >100000) deswegen wollte ich da nicht einfach in eine Textdatei reinschreiben weil ich dachte das wär wohl zu langsam).
Falls meine Idee mit TFileStream da Schwachsinn ist wärs auch nett mir das mitzuteilen
Also hab ich mir erstmal folgendes zusammengeschrieben (funktioniert nur leider nicht, war aber eigentlich klar weil ich von TFileStream keine Ahnung hab und nur einmal ID3-Tags damit ausgelesen habe):

Delphi-Quellcode:

     //Wort ist mit einem String gefüllt und muss "nur" noch gespeichert werden
     //Datei Worter.liste ist im Ordner (habs einfach mal .liste genannt, macht das was?)
     //Buffer ist ein String
     try
     FS:=TFileStream.Create('Worter.liste',fmOpenRead); 
     SetLength(Buffer,FS.Size);
     FS.Seek(0,soFromBeginning);
     FS.read(Buffer,FS.Size);
     finally
     FS.Free;
     end;
     if pos(Wort,Buffer)=0 then
     begin
     try
     FS:=TFileStream.Create('Worter.liste',fmOpenWrite);
     FS.Seek(0,soFromEnd);
     Buffer:=Buffer+Wort;
     FS.write(Buffer,(length(Buffer)-FS.size));
     finally
     FS.Free;
     end;

Warum funktioniert das nicht und wie könnte das klappen, wie würdet ihr das machen?
Danke im voraus
Flippo

[Dax]

String speichert man so:

Delphi-Quellcode:

procedure SaveString(S: String; Dest: TStream);
var i: Integer;
begin
  i := Length(S);
  Dest.Write(i, sizeof(i));
  Dest.Write(S[1], i);
end;

[Grishnak]

...und so lädt man sie wieder:

Delphi-Quellcode:

function LoadString(Source: TStream): string;
var
  len: integer;
begin
  Source.Read(len, SizeOf(len));
  SetLength(Result, len);
  Source.Read(Result[1], len);
end;

[marabu]

Hallo Flippo,

mach dir das Leben nicht unnötig schwer. Ich habe auf meinem alten P4 gerade einmal 1 Mio random strings variabler Länge (1..15) mit Add() in eine unsortierte StringList geschrieben [0.79 sec]. Dann habe ich die Liste mit Sort() sortieren lassen [13.92 sec] und anschließend habe ich sie mit SaveToFile() auf die Platte geschrieben [1.39 sec]. Abschließend habe ich die Datei wieder mit LoadFromFile() in die geleerte Liste eingelesen [0.66 sec]. Hit und Miss Tests habe ich mir geschenkt.

Grüße vom marabu

[tigerman33]

Ich kann mir nicht eigentlich nicht vorstellen, dass es länger dauert eine Textdatei zu laden als einen binary stream. Dem Rechner ist es egal, was für Daten er über den Bus schaufelt, und wenn du in den Filestream die Strings reinschreibst, stehen die da ja auch als ASCII-Codes drin. Das wär ja nichts anderes als mit einer Textdatei.

[Der_Unwissende]

Zitat von tigerman33:

Ich kann mir nicht eigentlich nicht vorstellen, dass es länger dauert eine Textdatei zu laden als einen binary stream. ... Das wär ja nichts anderes als mit einer Textdatei.

Ich glaube dass kann man so nicht sagen. Natürlich ist dem Rechner bei einem FileStream komplett egal, was für Daten er vorfindet. Da bekommt er nur einen Zeiger auf ein ByteArray mit dem man machen kann was man will (mehr oder weniger). Bei einem Textfile (denke jetzt an die ?Klasse?/Typ TextFile und File) sind da schon ganz andere (soweit ich in Erinnerung habe deutlich langsamere) Algorithmen am Werk (aber glaube du meitest dem Stream ist es egal).
Und nun ja, ein TStrings-Objekt muss natürlich auch ein paar Kleinigkeiten machen, immerhin wird die gesamte Datei in mehrere Zeilen (mittels CR+LF getrennt) gespeichert. Das ist natürlich mehr Overhead als ein Stream, aber wenn du die Datei eh Zeilenweise benötigst, kannst du davon ausgehen, dass TStrings schon einen sehr schnellen Weg benutzt. Ansonsten geht vieles mit einer THashedStringlist nochmal schneller, aber ich denke mal, dass die von Marabu geposteten Zeiten schon für sich sprechen. Warum also unnötig kompliziert wenn es einen Weg gibt der macht was du möchtest?

Gruß Der Unwissende

[tigerman33]

Um in einem Stream die Strings ohne LF/CR trennen zu können, musst du vorher die Stringlänge abspeichern. Ein Byte reicht da oft nicht aus (255 Zeichen sind schnell erreicht), nehmen wir also realistischerweise ein Wort. Du liest also Stringlänge (2 Byte) + String (x Byte).
In einer Textdatei liest du String (x Byte) + LF (1 Byte) + CR (1 Byte).
Macht also keinen Unterschied.
(Selbst wenn man die Länge auf nur ein Byte beschränkt, hat man günstigstenfalls ein Byte gespart.)

Über die Algorithmen kann ich nichts sagen, die hab ich nämlich nicht geschrieben.

[Der_Unwissende]

@tigerman33 Ja, gut, kannst in einem Stream auch die Länge speichern, aber musst du nicht. Könntest auch den Stream parsen und nach CR+LF oder eigenen Trennzeichen durchsuchen. Ganz klar ist, ein Stream behandelt die Daten nur als Bytes und damit entfällt eigentlich jeder Overhead beim Laden/Speichern (ok speichern nur bedingt, aber sehr kleiner Overhead). Aber die geladenen Daten zu interpretieren bringt dann die eigentliche Arbeit.
Nebenbei bemerkt, es ging ja auch nicht um Platz, oder? Und ein Byte pro Zeile lohnt sich bei genügend kurzen Zeilen (< 255 Zeichen), egal. Bei wirklich großen Textdateien holt man eh mehr mit einem einfachen Packer raus, als mit den Trennzeichen

Was die Algorithmen angeht, so hab ich sie auch nicht geschrieben (und auch noch nicht in den Quellcode geschaut), aber ich gehe jetzt nur davon aus, dass Delphi durchdachte Komponenten ausliefert (ok, macht eher Borland). Jedenfalls werden die Jungs dort dafür bezahlt sich mit effizienten Algorithmen zu befassen und die Grundidee ist doch, dass man gekapselte Objekte bekommt, deren konkrete Implementierung einen nicht interessieren soll. Aber wenn es einen tolleren schickeren schnelleren Algorithmus zum Suchen von Strings gibt, dann wird der wohl einfach intern geändert und dank Kapselung merke ich nur dass alles schöner toller besser läuft (anders gesagt gar nichts).

[tigerman33]

Nein es ging nicht um Platz. Mein erster Post bezog sich auf die Aussage vom Threadsteller, dass er Streams nimmt, weil Textfiles langsamer sein müssten. Das glaube ich eben nicht.

Auch ein Textfile behandelt die Zeichen nämlich nur als Bytes. Damit werden in beiden Fällen nur die Schritte gemacht:
1. Bytes von Platte schaufeln
2. Als String interpretieren

Nur dass man halt bei Streams den 2. Schritt sozusagen selber machen musst. Und wenn du dann auch noch anstatt die Länge zu speichern nach LF/CR parst, hast du ja letztlich nichts anderes gemacht, als das Textfile (ich mein jetzt den Typ) zu emulieren. Meine Aussage wo ich die Bytes gegeneinander aufgerechnet habe zielte daher auch nur darauf ab, zu zeigen, dass im Textfile-Fall nicht mehr Bytes gelesen werden müssen, denn das würde ja wiederum die Geschwindigkeit drücken.

Und da ich (wie du) davon ausgehe, dass Borland durchdachte Komponenten ausliefert, sage ich summa summarum:
Ein Stream ist hier verschenkte Liebesmüh, weil es auf nichts anderes hinausläuft, als die vom Textfile bereitgestellte Funktionalität neu zu implementieren. Im günstigsten Fall genauso schnell, wahrscheinlich aber langsamer.

[Flippo]

Ok Danke nochma, Problem gelöst