TFileStream: Später nochmal auf unveränderte Datei zugreifen

[Dezipaitor]

Also nehmen wir mal an, dass Festplatten schneller wären als der Hauptspeicher. Was würde das bedeuten?
1. Ich hätte die Festplatten schon längst verbannt.
2. Ich hätte 2000 TB Hauptspeicher
3. Mein PC würde rund um die Uhr laufen; ich hätte Windows durch Linux ersetzt (wegen den Abstürzen); würde eine riesige Stromrechnung haben;
und nicht schlafen können, weil die Kühler so laut sind
4. Ich würde jedesmal aus dem Fenster springen (2.Stock), wenn mein PC abstürzt, weil dann alle Daten verloren sind (aktueller RAM ist noch flüchtiger Speicher)

Ja, Hauptspeicher ist (in den allermeisten Fällen) schneller als Festplattenspeicher - dafür aber kostbarer (da weniger vorhanden).
Man muss jedoch beachten, dass Wasser durch schmale Röhren länger braucht, um ans Ziel zu kommen, als durch breite Rohre.
Also lieber nicht Wass..äh Daten byteweise in den Speicher schaufeln, sondern in größeren Stücken ("Wieviel darf's denn sein?"). Dann klappts auch mit der Geschwindigkeit.

P.S.
Macht dir nichts aus dem Stil meiner Antwort - ich hab zuviel The old new thing gelesen

[Martin K]

o_O ich stelle grad fest, dass ist mit TMemoryStream ist nicht nur schneller, das ist viel schneller.
Danke für den Tipp

Scheint so, dass das Einlesen Byte für Byte länger brauch, als TMemoryStream.LoadFromFile().
Z.B. bei einer 1,5 MB großen Datei hat die erste Variante schon ein paar Sekunden gedauert, mit TMemoryStream dagegen gehts so schnell, da kann man gar nicht gucken

Danke nochmals!

//Edit:

Zitat von Dezipaitor:

sondern in größeren Stücken ("Wieviel darf's denn sein?"). Dann klappts auch mit der Geschwindigkeit.

Ja, das ist die Frage - wie groß sind die Stücke im Idelfall?
Also bei meinem Beispiel einer 1,5 MB großen Datei dürfte das bei 1 GB RAM kein Problem sein, oder?
Wobei das natürlich bei Dateien jeder beliebigen Größe optimal gehen sollte...

[Dax]

Wenn deine Prozedur die Datei byteweise einliest und verarbeitet, mach do sowas:

Delphi-Quellcode:

var
  fs: TFileStream;
  buffer: array[0..32767] of Byte;
  byteCount, i: Integer;
begin
  fs := ... ;
  repeat
    byteCount := fs.Read(buffer, sizeof(buffer));
    for i := 0 to byteCount do 
      verarbeite buffer[i];
    until byteCount = 0;
end;

Damit dürfte immer alles recht fix gehen, bei minimaler Speicherbelastung.

[Martin K]

OK, das sieht ganz gut aus, für die 32767 dann am besten eine Konstante nehmen, so kann man es leicht ändern.
Kleiner Schönheitsfehler: In der For-Schleife muss es byteCount-1 heißen.

Könnte man das Ermitteln von sizeof(buffer) nicht auch durch das Verwenden einer Konstante performanter machen?

Ist jetzt vielleicht ein wenig OT, aber ich muss die Datei eigentlich Bitweise lesen, aber der Buffer geht nicht zufällig auch mit einem array of Boolean?
Ich habe es halt bisher so gemacht, dass ich das eingelesene Byte in einer weiteren For-Schleife jeweils um i nach rechts Shifte und dann eben mit and 1 ...

[Dax]

Zitat von Martin K:

Kleiner Schönheitsfehler: In der For-Schleife muss es byteCount-1 heißen.

In der Tat.. Entschuldige

Zitat von Martin K:

Könnte man das Ermitteln von sizeof(buffer) nicht auch durch das Verwenden einer Konstante performanter machen?

sizeof ist Compilermagic, das wäre also unnötig.

Zitat von Martin K:

Ist jetzt vielleicht ein wenig OT, aber ich muss die Datei eigentlich Bitweise lesen, aber der Buffer geht nicht zufällig auch mit einem array of Boolean?
Ich habe es halt bisher so gemacht, dass ich das eingelesene Byte in einer weiteren For-Schleife jeweils um i nach rechts Shifte und dann eben mit and 1 ...

Nöp, das geht nicht. Du musst wohl mit der Schleife leben.

[Martin K]

Gut, danke nochmal an alle, werde das dann mal soweit umsetzen.

[Olli]

Wenn du unterhalb von (RAM+Auslagerungsdatei)-Größe bleibst, sollte es keine Probleme geben. Allerdings solltest du beachten, daß andere Anwendungen laufen und das OS selber auch RAM braucht - zieh also noch einen großen Brocken davon ab und dur bist immer auf der sicheren Seite. Ab Windows 2000 solltest du bspw. ohne weiteres 64 MiB laden können. Soweit ich weiß benutzt das ja auch MMFs und wenn die Implementierung korrekt ist, wird sich der Memory-Manager drum kümmern, daß die Daten im Speicher verfügbar sind (wobei Speicher nicht gleichzusetzen ist mir phys. RAM - schließlich reden wir über Usermode)

[Dezipaitor]

Zitat von Martin K:

Ist jetzt vielleicht ein wenig OT, aber ich muss die Datei eigentlich Bitweise lesen, aber der Buffer geht nicht zufällig auch mit einem array of Boolean?
Ich habe es halt bisher so gemacht, dass ich das eingelesene Byte in einer weiteren For-Schleife jeweils um i nach rechts Shifte und dann eben mit and 1 ...

In der grauen Vorzeit hat man sich geeinigt, dass Computer Bytestreams verarbeiten und nicht Bitstreams. Es gab damals ja auch noch die Lochkarten,
welche Bits darstellten. Aber schon damals hat man mehrere Bits zusammengefasst.

Die Frage kommt sehr oft im Forum.

[Martin K]

Danke nochmals für eure Antworten

Zitat von Olli:

Soweit ich weiß benutzt das ja auch MMFs und wenn die Implementierung korrekt ist, wird sich der Memory-Manager drum kümmern, daß die Daten im Speicher verfügbar sind

Kannst du das mal genauer erklären?
Was ist MMF?

Ich habe irgendwie immernoch folgendes Problem:
Für kleinere Textdateien ist die von Dax vorgeschlagene Buffergröße von 32 KB vielleicht ganz gut, aber wenn ich eine mehrere MB große Datei habe, wäre eine Buffergröße von 64 MB nicht schlecht (wie Olli sagt, dürfte das kein Problem sein).
Allerdings wenn ich dann bei dem 64 MB großen Buffer nur eine kleine Textdatei einlese mit ein paar KB, dann belege ich ja trotzdem die 64 MB im Speicher -> nicht so optimal.
Was empfehlt ihr?
Vielleicht doch wieder TMemoryStream verwenden?

[Olli]

Zitat von Martin K:

Was ist MMF?

Memory Mapped Files

Zitat von Martin K:

Vielleicht doch wieder TMemoryStream verwenden?

Ja