Memo1.Text.Length erzeugt "Integer Overflow"

[freejay]

Hallo zusammen,

ich kann in einem Programm (64Bit) massiv Daten in ein TSynMemo schreiben (~ 3 Mio. Zeilen á 50-100 Zeichen) ohne dass ein Fehler auftritt. Der Speicherbedarf des Programms ist dann laut TaskManager bei ca. 3GB.

Versuche ich aber die Anzahl der Zeichen zu bestimmen mit

Delphi-Quellcode:

Memo1.Text.Length

, dann bekomme ich einen "Integer Overflow"-Fehler.

Delphi-Quellcode:

length(Memo1.Text)

funktioniert ebenfalls nicht.

Kann mir jemand sagen warum und/oder wie ich alternativ die Anzahl der Zeichen bestimmen kann (außer über eine Loop über alle Zeilen: Das würde viel zu lange dauern...).

Danke im Voraus!

Freejay

[Uwe Raabe]

Was ist mit

Delphi-Quellcode:

Memo1.GetTextLen

?

[Neutral General]

Ganz einfach. Die Anzahl der Zeichen ist über 2^31-1 (2GB), Passt also nicht in einen Integer.
Du musst wahrscheinlich selbst zählen mit nem Cardinal oder Int64.

VIELLEICHT kannst du tricksen und folgendes klappt:

Delphi-Quellcode:

var len: Cardinal;
begin
  len := PCardinal(Cardinal(Memo1.Text)-SizeOf(Cardinal))^
end;

Das ist aber getrickst und ich bin mir nicht sicher, ob das bei so großen Strings klappt.

[Uwe Raabe]

Zitat:

Zitat von Neutral General (Beitrag 1371951)

Ganz einfach. Die Anzahl der Zeichen ist über 2^31-1 (2GB)

Sicher?

Zitat:

~ 3 Mio. Zeilen á 50-100 Zeichen

sind in etwa 300 Millionen Zeichen, aber noch lange nicht 3000 Millionen.

[Neutral General]

Zitat:

Zitat von Uwe Raabe (Beitrag 1371960)

Zitat:

Zitat von Neutral General (Beitrag 1371951)

Ganz einfach. Die Anzahl der Zeichen ist über 2^31-1 (2GB)

Sicher?

Zitat:

~ 3 Mio. Zeilen á 50-100 Zeichen

sind in etwa 300 Millionen Zeichen, aber noch lange nicht 3000 Millionen.

Recht hast du :gruebel: Auf der anderen Seite klingt Integer-Overflow aber stark nach einer Länge von über High(Integer).

[SneakyBagels]

Ich werfe einfach mal was anderes in den Raum.
Ich hatte in einem frischen Projekt auch schon den Integer-Overflow-Fehler... beim Create einer TMemIniFile.
Zwar nicht bei 10.1 sondern bei 10.2.

[Uwe Raabe]

Ich sehe gerade, daß es gar nicht um TMemo sondern um TSynMemo geht. Dann ist mein Vorschlag leider nicht gültig. Allerdings würde dann wohl auch ein simples Debugging zur Quelle des Problems führen.

[hoika]

Hallo,
Watchpoint setzen, Wert anzeigen lassen, mit Maxint vergleichen (nicht 4 GB, sondern 2 GB).
Und dann die Sache mit Int64.

Hat das SynMemo keinen Quellcode?

[nahpets]

Zitat:

Zitat von freejay (Beitrag 1371945)

(außer über eine Loop über alle Zeilen: Das würde viel zu lange dauern...).

SynMemo hat das Attribut Lines. Das ist vom Typ TStrings. Wenn man sich nun anschaut, wie TStrings an den Inhalt von Text kommt, dann stellt man fest, dass in einer Schleife von 0 bis Count - 1 jede Zeile an einen String angehängt wird.
Hier wurde also bereits einmal zum Ermitteln von Text über die alle Zeilen iteriert.
Damit das Ganze funktioniert wird auch für jede Zeile die Länge des Zeileninhaltes ermittelt.

Kann mir nicht vorstellen, dass ein Iterieren über alle Zeilen und das Summieren der jeweiligen Zeilenlänge länger dauert, als eben eine Aufgabe, die genau dies als Teilmenge enthält.

Der Eigenbau hätte hier dann auch noch den Vorteil, dass man für die Summe einen Typen wählen kann, der ausreichend groß ist.

Da die Länge niemals kleiner 0 sein wird, kann man dann auch direkt einen Typen wählen, der nur positive Werte zulässt.

Zitat:

Zitat von Delphi 7-Sourcen zu TStrings

Delphi-Quellcode:

...
TStrings = class(TPersistent)
...
property Text: string read GetTextStr write SetTextStr;

Einfach mal in die Quellen von

Delphi-Quellcode:

function TStrings.GetTextStr: string;

schauen. Bei Delphi 7 wird da mit Integer gearbeitet. Reicht das für die hier genutzten Inhalte des SynMemos aus oder kracht es da bereits intern, so dass eine eigene Typauswahl für das Ergebnis von Length nicht für die Fehlerbehebung ausreicht.

[freejay]

Danke für die bisherigen Antworten. Kann das erst morgen in der Arbeit testen/verifizieren.

In meinen heutigen Versuchen ist es mir nicht gelungen, an den Quelltext von Length() heranzukommen. Angezeigt wurde, dass Length in Unit System definiert ist, ist es aber nicht (oder ich bin blind...). Ich nahm daher an, dass das so eine compilerinterne Geschichte ist. Vielleicht ist in meinen Debug-Settings irgendwas verqueer...

[Uwe Raabe]

Zitat:

Zitat von freejay (Beitrag 1371974)

In meinen heutigen Versuchen ist es mir nicht gelungen, an den Quelltext von Length() heranzukommen.

Length ist wohl auch nur der letzte Schritt. Womöglich kommt der Fehler schon vorher.

[SneakyBagels]

Könnte das hier nicht der Code von Length sein?

Delphi-Quellcode:

function __StringLength(.... // Rückgabewert immer Integer
begin
 Result := PInteger(PByte(S) - 4)^;
end;

Setz doch einfach mal ein paar MessageBoxen einige Zeilen vor und einige nach Length. Irgendwo wird der Fehler dann sein denke ich.

[jaenicke]

Ich frage mich eher was der Sinn ist. 3 Millionen Zeilen kann doch niemand jemals lesen. Bist du sicher, dass ein TSynMemo hier sinnvoll ist?

[nahpets]

Interessant ist in dem Zusammenhang auch, dass für die Datenmenge 3 GB benötigt werden.
Das erscheint mir irgendwie deutlich zuviel zu sein.
3.000.000 Zeilen * 100 Zeichen = 300.000.000 Zeichen

3 GB ist irgendwie deutlich mehr.

TSynMemo liefert doch eine Syntaxhervorhebung. Wird die benötigt?

Was ist eigentlich die ursprüngliche Aufgabenstellung, für die die Anzahl der Zeichen ermittelt werden soll? Eventuell gibt es ja 'ne andere Zählmöglichkeit.

[himitsu]

100 Zeichen á 2 Byte
und dann noch die Speicherfragmentierung, wenn man jede Zeile einzeln speichert.

TMemo ist auch nicht besser, denn da wird das in einem Speicherblock abgelegt und man braucht das GB auch an einem Stück, was unter 32 Bit praktisch nahezu unmöglich ist, selber mit aktiver 3 oder 4 GB-Erweiterung.



Allerdings könnte man sich auch fast fragen, warum überhaupt alle Zeilen unbedingt gleichzeitig in den Speicher müssen.
Will sich das wirklich jemand ALLES ansehn?

Entweder die Daten filtern und nur eine menschenlesbare Menge anzeigen,
oder es gibt auch Edits, die nur den jeweils grade sichtbaren Teil laden.

[freejay]

Liebe DP-Gurus (das ist absolut positiv gemeint!!!),

das war ja klar das die übliche Frage "ist es überhaupt sinnvoll..." aufkommt... ;-) Dann erklär ich das mal:

Ja, ist es, denn es handelt sich bei dem Programm um einen "Editor", dessen Spezialgebiet die Analyse, Filterung und Umstrukturierung von Textdatei-basierten Daten ist. Es ist nicht "just another Quelltexteditor"... ;-)

Er wird ständig unseren Bedürfnissen angepasst und ist ein unverzichtbares Tool geworden, wenn man "mal schnell was in den Daten nachsehen" oder Dateiformate "umbasteln" muss.

Aufgrund der Historie de Programms und wegen der Performance muss dabei alles im Speicher ablaufen.

Da ich vor einer Schulung Beispieldateien zusammen suchen wollte, die z.B. demonstrieren, welch große Dateien man damit bearbeiten kann, bin ich über das Length-Problem gestolpert.

Es wird dabei übrigens String.Length (ein String-Helper) benutzt. Auch die Funktion Length() packt's ab einer bestimmten Größe nicht mehr, obwohl der String die Daten aufnehmen kann - es waren Übrigens rund 1,3 G Zeichen.

Der Vorschlag, die Länge selbst in einer Loop über die Zeilen zu bestimmen, erschien mir zunächst performance-technisch völlig ungeeignet, da bei jeder eingabe eines Zeichen im Editor diese Zahl neu angezeigt - und damit auch berechnet werden muss.

ABER: Ich hab's trotzdem ausprobiert und es dauert auch bei 3 Mio Zeilen nur den Bruchteil einer Sekunde!

Damit ist also mein Problem gelöst.

Vielen Dank allen!

Gruß

Freejay

[Uwe Raabe]

Zitat:

Zitat von freejay (Beitrag 1372012)

Der Vorschlag, die Länge selbst in einer Loop über die Zeilen zu bestimmen, erschien mir zunächst performance-technisch völlig ungeeignet, da bei jeder eingabe eines Zeichen im Editor diese Zahl neu angezeigt - und damit auch berechnet werden muss.

In dem Fall geht aber die meiste Zeit damit verloren, den Rückgabewert des Text-Properties aus den einzelnen Strings zusammenzusetzen. Das ist um ein Vielfaches aufwändiger als einfach alle Zeilenlängen zusammenzurechnen.

Du solltest aber beachten, daß Text für jede Zeile ein CRLF anfügt. Dadurch ist die Length(Text) nicht identisch mit Sum(Length(Lines[I]))!

[nahpets]

@Uwe

Wie wäre es denn damit?

Delphi-Quellcode:

function TextLength(sl : TStrings) : Cardinal;
var
  i : Cardinal;
  k : Cardinal;
begin
  Result := 0;
  k      := Length(sLineBreak);
  for i  := 0 to sl.Count - 1 do Inc(Result, Length(sl[i]) + k);
end;

[freejay]

Zitat:

Zitat von nahpets (Beitrag 1372027)

@Uwe

Wie wäre es denn damit?

Delphi-Quellcode:

function TextLength(sl : TStrings) : Cardinal;
var
  i : Cardinal;
  k : Cardinal;
begin
  Result := 0;
  k      := Length(sLineBreak);
  for i  := 0 to sl.Count - 1 do Inc(Result, Length(sl[i]) + k);
end;

Im Prinzip mache ich das genau so.

[Ydobon]

Zitat:

Zitat von freejay (Beitrag 1372012)

ABER: Ich hab's trotzdem ausprobiert und es dauert auch bei 3 Mio Zeilen nur den Bruchteil einer Sekunde!

Damit ist also mein Problem gelöst.

Und welche Größe ergibt sich nun?

[freejay]

Zitat:

Zitat von Ydobon (Beitrag 1372032)

Zitat:

Zitat von freejay (Beitrag 1372012)

ABER: Ich hab's trotzdem ausprobiert und es dauert auch bei 3 Mio Zeilen nur den Bruchteil einer Sekunde!

Damit ist also mein Problem gelöst.

Und welche Größe ergibt sich nun?

Wie ich schon oben "schrub": Etwa 1,3 G also ca. 1,4 Milliarden

[himitsu]

also fast 3G

Delphi-Quellcode:

Result := 0;
for i := 0 to SL.Count - 1 do
  Inc(Result, (Length(SL[i]) + LB) * SizeOf(Char));

Result := 0;
for S in SL do
  Inc(Result, (Length(S) + LB) * SizeOf(Char));

Result := 0;
for S in SL do
  Inc(Result, Length(S));
Result := (SL.Count * Length(sLineBreak) + Result) * SizeOf(Char); // (SL.Count-1) ... wenn kein Zeilenumbruch nach der letzten Zeile, aber die 2 Byte ...

[SneakyBagels]

Zitat:

Wie ich schon oben "schrub": Etwa 1,3 G also ca. 1,4 Milliarden

Es heißt schrieb. Das Wort schrub gibt es nicht. :thumb: