Vermutlich ebenfalls möglich wäre ein TFileStream (oder TStringReader, wenn der intern auch so funktioniert), der die Dinge in einem Array von RawBawbyteString ablegt, grundsätzlich wäre es aber gut, die Zeilenzahl zu kennen.
Tfilestream zu verwenden war eine gute Idee fürs Laden und Speichern der eigenen Datendatei, da ich so das zusätzliche Anlegen von großen TMemorystreams vermeiden kann. Wenn die
DB verschlüsselt ist, muss ich allerdings doch wieder TMemorystream verwenden, da das verschlüsseln und entschlüsseln auf einem TFilestream zu langsam ist. Letztlich aber nicht so schlimm, da ich die Verschlüsselung immer nur auf eine komprimierte Datei anwende, die ist deutlich kleiner als die eigentliche Datenmenge und das dekomprimieren der entschlüsselten Datei geht zügig genug mit dem Filestream.
Mit den ganzen Optimierungen ist es mir jetzt immerhin gelungen (in der Windows 64-Bit bzw. Linux-64-Bit-Version mit mindestens 16 GB
RAM) die 2,1 GB große
csv-Datei mit über 15 Mio. Datensätzen zu importieren und in meinem komprimierten Datenformat zu speichern (dann werden da ca. 600 MB draus). Wie gesagt, arbeiten kann man damit dann nicht mehr flüssig (z.B. die "Life"-Filterung wird dann extrem hakelig und laden und speichern dauert z.B. einige Sekunden), also nach wie vor bleibt es bei der Zielgruppe der User, die nicht mehr als 100.000 - 200.000 DS mit dem Programm bearbeiten müssen. Hat aber einfach Spaß gemacht, die Leistungsgrenzen mal ein wenig aufzubohren und ein wenig mehr Gefühl dafür zu bekommen, bei welchen Aktionen u.U. schnell ein großer Speicherverbrauch auftreten kann.
Letztlich hat das auch dazu geführt, dass ich unter Windows erstmals eine 64-Bit-Version eines Programm veröffentlicht habe, denn mit dem Wegfall der 2 GB Speichergrenze in der 64-Bit-Programmfassung kommt man in diesem Fall dann doch deutlich weiter... (wäre schön, wenn Delphi - das ja auch noch ein 32-Bit-Programm ist - da gleichfalls mal bald nachziehen würde...
)