Delphi und 64-Bit Programme

[Sinspin]

Zitat von Uwe Raabe:

Allein schon das Hantieren mit 2GB Strings ist schon heikel genug. Bei jedem Copy-on-Write werden da mal eben weitere 2GB am Stück belegt. Einige Dinge sollte man mit so großen Strings einfach nicht machen. 64-Bit hin oder her, das ist einfach Verschwendung und schreit schon wegen der Performance nach einem anderen Ansatz.

Es geht ja nicht um die Realität, sondern um die theoretische Fähigkeit es tuen zu können ohne das es knallt.

Allerdings ging es garnicht um String sondern um TStrings (System.Classes.TStrings ).

Zitat von Uwe Raabe:

Man stelle sich nur mal vor, man würde eine 32GB Textdatei in einen solchen 64-Bit String einlesen.

Genau um sowas, eine Datei die etwas größer ist, in TStrings zu laden.
Also ein Zeilenweises array of String. Das sollte doch gehen?
Interessant ist die Frage, was passiert bei den Properties CommaText und Text, denn die sind String .

[jaenicke]

Zitat von Sinspin:

Genau um sowas, eine Datei die etwas größer ist, in TStrings zu laden.
Also ein Zeilenweises array of String. Das sollte doch gehen?
Interessant ist die Frage, was passiert bei den Properties CommaText und Text, denn die sind String .

Genau deshalb klappt das ja nicht. Die Implementierung könnte man (abgesehen von diesen Properties) relativ einfach anpassen, damit Dateioperationen möglich wären.

Aber mit TFileStream usw. gibt es ja sinnvolle Möglichkeiten für große Dateien.

[Uwe Raabe]

Zitat von Sinspin:

Genau um sowas, eine Datei die etwas größer ist, in TStrings zu laden.
Also ein Zeilenweises array of String. Das sollte doch gehen?

Das tut es ja jetzt schon, wenn man es entsprechend lädt. Also nicht mit Zuweisung von Text, CommaText oder LoadFromFile bzw. LoadFromStream. Die würden in der Tat 64-Bit Strings erfordern.

Zitat von Sinspin:

Interessant ist die Frage, was passiert bei den Properties CommaText und Text, denn die sind String .

Eben, das knallt dann halt. Das ist aber meiner Meinung nach durchaus OK. Es ist eigentlich nicht zu rechtfertigen, dass man, nur um solche Sonderfälle abzudecken, den ganzen Unterbau auf 64-Bit Verträglichkeit auslegt. Auch in 64-Bit sind die meisten TStrings Instanzen mit überschaubaren Inhalten versehen.

Aber wie Sebastian schon schreibt, spricht ja auch nichts dagegen eine Ableitung von TStringList zu schreiben, bei der die LoadFromStream/SaveToStream Implementierungen eben nicht über SetTextStr/GetTextStr laufen. Dann könnte man diese ja auch für größere Dateien verwenden.

Als Nebeneffekt würde auch der interne Buffer für das Encoding wegfallen. Da liegt nämlich auch noch ein Speicherfresser: Erst wird ein Buffer angelegt, der den kompletten Inhalt der Datei in den Speicher lädt. Dann wird daraus anhand des Encodings ein String gemacht, bevor dieser dann zeilenweise zerlegt in die interne Liste wandert. Das braucht dann temporär mal eben so etwa 5x soviel Speicher wie die Datei groß ist (danach dann 2x).

Wie man dann allerdings halbwegs performant mit so einer Monster-Stringliste umgehen soll steht auf einem anderen Blatt.