Textdatei laden - Integerüberlauf

[Michael II]

Leider kann ich mit 10.4 nicht mehr Win64Bit debuggen - es steht immer sofort "disconnected session" - und das war's. Und ein anderes Delphi habe ich grad nicht.

Aber laufen lassen kann ich 64 Bit Programme: Wenn ich zu einer TStringList 50 Mio Mal den string '012345678901234567890123456789' hinzufüge, dann klappt dies. Wenn ich dann savetofile aufrufe, dann gibt's auch hier einen Integerüberlauf.

Der von dir erwähnte Integerüberlauf tritt also nicht nur beim Laden, sondern auch beim Speichern auf.

[himitsu]

Der 64 Bit-Debugger wird, wie der externe RemoteDebugger, über eine lokale TCP/IP-Verbindung angesprochen ... schau mal ob rmtdbg270.exe lokal freigegeben ist.


So, ansonsten du hast Pech.
Im SaveToFile wird erst alles in einen String kopiert
und strings können maximal 2 GB groß werden.

Bei DynArrays ist Length als NativeInt deklariert, aber bei den LongStrings (z.B. String/UnicodeString) nur als Integer.

TStrings.SaveToStream: erst über TStrings.GetTextStr und dann durch TEncoding.GetBytes in ein Byte-Array, welcher in den Stream kopiert wird
und der String ist hier die Limitierung.
Beim LoadFromFile andersrum.


Du darfst gern eine TStringList benutzen, aber nur für Dateien unter 1 GB,
oder du implementierts die Lade-/Speichernfunktion selbst.

Oder machst es eben "richtig".

Zitat:

Das "richtige" Verfahren ist aber nicht ALLEs zu laden, sondern solche großen Dateien nur stückchenweise in mehreren Blöcke á einigen KB/MB aufgeteilt zu laden und nacheinander zu behandeln.

Sieh dir HxD an, da hast ein Beispiel dass man auch kleine Terrabytedateien laden kann.

[bernau]

Zitat von himitsu:

Oder machst es eben "richtig".

Definiere "richtig".

Der TE hat nicht geschrieben, was er mit der Textdatei machen möchte.

Wenn zur Auswertung der Textdatei wahllos zwischen den Zeilen hin und her gesprungen werden muss, dann bleibt nichts anderes übrig, als die Datei komplett einzulesen. Ausser die Textdatei hat eine feste Zeilenlänge. Aber auch das weist du nicht.

[Bbommel]

Der TE hat doch schon längst geschrieben, dass er große Dateien jetzt zeilenweise per StreamReader einliest.

[himitsu]

Zitat:

Wenn zur Auswertung der Textdatei wahllos zwischen den Zeilen hin und her gesprungen werden muss, dann bleibt nichts anderes übrig, als die Datei komplett einzulesen.

In den dem Fall würde ich die Datei eher in den Speicher mappen, anstatt reinzuladen,
da hier der FileCache von Windows ins Spiel kommt und diese Datei nicht "komplett" im RAM/Auslagerungsdatei abgelegt wird.
MemoryMappedFiles

Bei sequentiell ist ein StreamReader aber bestimmt einfacher.

Wobei, bei der MMF kann man da den Anfang und Ende als PAnsiChar/PWideChar casten und kann gemütlich dazwischen durch den Arbeistspeicher hüpfen, während sich Windows um das Laden kümmert (bzw. Entladen, wenn freier RAM benötigt wird).
z.B. der Code oder die Ressourcen von EXE und DLL sind ebenso in den Speicher gemappt, so dass es nicht in die Auslagerungsdatei muß, da es von der Platte geladen und notfalls entladen werden kann. Abgesehn davon wo Code/Speicher/Adressen angepasst wurden, dann wird der Teil von der Datei entkoppelt (CopyOnWrite) und bleibt im RAM/Auslagerungsdatei.

[hoika]

Hallo,
wenn das SaveToFile nicht klappt,
dann schreib es per AssignFile, WriteLn (Typ: Text) usw.;

[Michael II]

Hallo in die Runde... nur kurz: Ich will gar nicht viele Elemente einer TStringlist speichern. Es war nur eine Bemerkung, dass sowohl das Laden via loadfromfile (ursprüngliches Thema des Threads) wie eben auch das Speichern via savetofile nicht klappt. Grund ist klar (siehe oben).

[ Danke himitsu für deinen 64Bit Win Debugger Firewall Tipp (Einstellung war und ist OK) - wenn ich keine Lösung finde, dann muss ich wohl mal ein neues Thema eröffnen. ]

[TurboMagic]

Zitat von Uwe Raabe:

Das LoadFromString/LoadFromStream ist in der Regel für die Begrenzung zuständig.

Delphi-Quellcode:

procedure TStrings.LoadFromStream(Stream: TStream; Encoding: TEncoding);
var
  Size: Integer;
  Buffer: TBytes;
begin
  BeginUpdate;
  try
    Size := Stream.Size - Stream.Position;
    SetLength(Buffer, Size);
    Stream.Read(Buffer, 0, Size);
    Size := TEncoding.GetBufferEncoding(Buffer, Encoding, FDefaultEncoding);
    SetEncoding(Encoding); // Keep Encoding in case the stream is saved
    SetTextStr(Encoding.GetString(Buffer, Size, Length(Buffer) - Size));
  finally
    EndUpdate;
  end;
end;

Obwohl Stream.Size und Stream.Position als Int64 deklariert sind, wird für die Differenz nur ein Integer bereitgestellt. Das nachfolgende SetLength muss dann noch einen zusammenhängenden Speicherbereich in der gewünschten Größe finden, was unter 32-Bit schnell mal zum problem werden kann. Aber auch dieses SetLength beschränkt die Puffergröße auf 2GB, weil NewLength auch nur ein Integer ist.

Allerdings sehe ich in diesem konkreten Fall erstmal keine dieser Grenzen überschritten.

Wäre das aber nicht trotzdem ein Kandidat für eine kleine Codeänderung durch EMBT?

[Uwe Raabe]

Zitat von TurboMagic:

Wäre das aber nicht trotzdem ein Kandidat für eine kleine Codeänderung durch EMBT?

Aber natürlich!

[himitsu]

Nur an der Stelle das zu Ändern ist völlig irrelevant, so lange es durch einen String gejagt wird, dann dafür ist hier der Integer als Typ vollkommen richtig, siehe mein Post.


PS, was CodeInsight für Typen beim SetLength anzeigt, ist auch irrelevant, verwirrend und falsch,
denn siehe DynArraySetLength in System.pas ist es für dynamische Arrays richtig als NativeInt deklariert,
aber eben bei den LongStrings immernoch als Integer. (sowohl Funktion, als auch im Typ)
Bezüglich der Compiler-Magic darfst eh nie dem trauen, was dir angezeigt wird.

Was extrem schwachsinnig ist, denn in 32 Bit sind seit jeher DynArray und LongString vom Aufbau her rundlegend kompatibel. (auch dort wo seit 2009 die CodePage und CharSize sich verstecken, ist im DynArray ein Platzhalter enthalten), was nun im 64 Bit aber nicht mehr passt. Und das hier auch zu diesem Problem führt.