Datei > 500mb vollständig in RAM laden

[Harry M.]

Moinsen DP

Wie bekomme ich meine Datei möglichst schnell in den RAM um sie dort wie ein TFielStream oder TMemoryStream zubehandeln. Den fs öffnen un in einen ms kopieren, scheint mir nicht der richtige Weg. (Hat zu lange gedauert - ein víelfaches länger als sie einfach nur zukopieren, und nachdem immer noch nicht fertig geladen wurde aber schon viel mehr Speicher drauf ging, habe ich die Sache abgebrochen.)

Aber vielleicht lags auch nur am Code :gruebel:

Delphi-Quellcode:

function LoadTable(AFileName: String; var AResult: TMemoryStream): Boolean; overload;
var
  fs: TFileStream;
begin
  Result := False;
  if FileExists(AFileName) then begin
    fs := TFileStream.Create(AFileName, fmOpenRead);
    AResult := TMemoryStream.Create;
    AResult.CopyFrom(fs, fs.size);
    fs.Free;
    Result := AResult.Size > 0;
    end;
end;

Weiß doch sicher wieder jemand bescheid?! :mrgreen:

[Die Muhkuh]

Hi Harry,

mach doch direkt ein MS.LoadFromFile ;-)

[edit]Wobei ich keinen Sinn dabei sehe, eine komplette 500mb Datei in den Ram zu laden. Was hast Du den vor? Vielleicht geht das auch anders. [/edit]

[Daniel]

Wie wäre es denn mit sog. "MemoryMapped Files" und die restliche Arbeit dem OS überlassen?

[Harry M.]

Äffffffffffffff. Genau das hab ich gestern gesucht und nich gefunden. :wall: :wall: :wall:
Danke.

[Harry M.]

Hi Daniel,
MemoryMapped Files - gutes Stichwort. Da guck ich doch ma nach :mrgreen:

Edit: Ich versuch grad so ne Art Datenbank zubauen. Ohne dabei wirklich auch ADO und Co zusetzten. Denn bei Test ist mir aufgefallen, mit zunehmender Grösse sank auch die Performance der SQL anfragen rapiede Schon nach 15 Min inserst bei anlegen, kamem Zeiten > 200ms raus, was nicht akzeptabel ist.

Ich schreibe jetzte meine Daten zuerst in den Speicher und sicher dort aller paar Minuten in eine Datei. Das geht besser.

[Der_Unwissende]

Zitat:

Zitat von Daniel

Wie wäre es denn mit sog. "MemoryMapped Files" und die restliche Arbeit dem OS überlassen?

Etwas ganz ähnliches sollte doch eigentlich schon beim FileStream passieren. Der arbeitet (afaik) mit einem Lesepuffer (zumindesten ist der Zugriff hier schon gut schnell!). An sich ist halt die Frage, warum Du so darauf bestehst, dass die komplette Datei im RAM landet. Das sicher zu stellen ist imho etwas aufwändiger. Selbst bei MemoryMapped Files hat halt das OS die Möglichkeit (korrigiert mich, wenn ich mich irre!) den Inhalt in den Virtuellen Speicher zu verschieben, der liegt natürlich wieder auf der Festplatte. Das man davon so schön wenig merkt ist gerade die Aufgabe des OS, aber letztlich dürfte es Dir keine Perfomance-Vorteile bringen, wenn Du hier eine Datei schon komplett in den RAM lädst (da geht eher Zeit verloren, wenn diese Menge an Daten ausgelagert wird weil Platz im RAM gemacht werden muss oder dies eben mit anderen Programmen geschieht, da deine 500 MByte einfach unnötig Speicher blockieren).

Gruß Der Unwissende

[Harry M.]

Zitat:

Zitat von Der_Unwissende

An sich ist halt die Frage, warum Du so darauf bestehst, dass die komplette Datei im RAM landet.
Gruß Der Unwissende

Bei Ich schreibe in die Datei pro Eintrag 8 byte und einen Long. Jeztz weisst Du vielviele Einträge in der Datei stehten, wenn ich ca von 500mb ausgehe. Potenzierung nicht ausgeschlossen. Das suchen in der Datei geht später schneller als wenn ich die 8 Byte zu vergleichen von Platte lese.

[Luckie]

Und bei einem 512 MB System bleiben dann noch 12 MB für Betriebssystem und dein Programm (das keine anderen Programme noch nebenbei laufen, habe ich gleich mal außen vor gelassen, da sehr unwahrscheinlich ist, dass man die noch gestartet bekommt bzw. vernünftig mit arbeiten kann). Selbst auf einem 1 GB System macht es nicht wirklich Freund zu arbeiten, wenn plötzlich die Hälfte vom Speicher fehlt.

Das die Performance in den Keller geht, wenn ich jedes Byte einzeln lade, dürfte irgendwie logisch sein. Arbeite mit einem entsprechenden Lesepuffer (512 KB) und du solltest auch keine Performance-Probleme haben.

[Der_Unwissende]

Zitat:

Zitat von Harry M.

Bei Ich schreibe in die Datei pro Eintrag 8 byte und einen Long. Jeztz weisst Du vielviele Einträge in der Datei stehten, wenn ich ca von 500mb ausgehe. Potenzierung nicht ausgeschlossen. Das suchen in der Datei geht später schneller als wenn ich die 8 Byte zu vergleichen von Platte lese.

Das ist klar, aber wenn Du einen Puffer verwendest, 8 Byte + sizeOf(Long) (denke ein Long ist in dem Bereich), z.B. 1.000.000 solcher Datensätze (knapp unter einem MByte), dann sollte das schon um einiges flinker gehen und sehr ressourcen-schonend arbeiten. Die größe des Puffers kannst Du natürlich auch sinnvoller wählen! Versuch einfach mal Werte zwischen ein paar Kilobyte und ein paar zig MByte und schau Dir an wie schnell was funktioniert.

[edit]
roter Kastern?!

Aber gleich eine Ergänzung, wie Luckie schon sagte, wirst Du schnell das Problem bekommen, dass Dir das OS schon gar nicht den gesamten RAM zur Verfügung stellen wird, es muss ja selbst auch noch laufen! Wenn sich dann 512 MByte noch potenzieren landest Du schnell bei den Grenzen eines 32-Bit Systems.
[/edit]

[Elvis]

Zitat:

Zitat von Harry M.

Hi Daniel,
MemoryMapped Files - gutes Stichwort. Da guck ich doch ma nach :mrgreen:

Edit: Ich versuch grad so ne Art Datenbank zubauen. Ohne dabei wirklich auch ADO und Co zusetzten.

Kein DBMS setzt auf ADO, außer dieser klägliche Versuch aus dem Hause MSFT. ADO ist eher ein Ärgernis, dass viele DBMS-Hersteller eingehen um damit Leute zu bedienen, die irgendwie ADO bevorzugen.
Diese doch sehr fundamentale Wissenslücke sollte dich eigentlich auf den Gedanken bringen, dass du dich a) nicht mit genügend unterschiedlichen DBMS auseinandergesetzt hast und das Ganze b) nicht lange genug (Erfahrung).

Jeder (JEDER) Versuch ein eigenes, auf eine spezielle App angepasstes, DBMS zu basteln, der mir bisher unter die Augen kam, war bestenfalls jämmerlich.

Zitat:

Denn bei Test ist mir aufgefallen, mit zunehmender Grösse sank auch die Performance der SQL anfragen rapiede Schon nach 15 Min inserst bei anlegen, kamem Zeiten > 200ms raus, was nicht akzeptabel ist.

Wenn deine Erfahrungen bei ADO aufhören, und wenn du schon bei solch' "simplen" Prblemenen scheiterst, wirst du keine Lösung hinbekommen, die mit einem embedded Firebird oder SQLite hinter einem eigenen Service auch nur ansatzweise konkurieren könnte.

Zitat:

Ich schreibe jetzte meine Daten zuerst in den Speicher und sicher dort aller paar Minuten in eine Datei. Das geht besser.

Und wie sicherst du ihn die Datei? Wonach entscheidest du was wann geschrieben werden muss? Was ist mit Stromausfällen oder gleichzeitigen Zugriffen?
Alles Dinge, die dir Firebird oder SQLite abnehmen würden, und beide machen diesen Job sehr gut. ;)