StrToInt langsam in D 10.4

[Sailor]

Du hast irgendwo in der Umgebung einen Breakpoint gesetzt. Lösche mal alle und versuch‘s noch mal.

[jaenicke]

Vor allem Breakpoints mit Bedingung verlangsamen den Prozess extrem.

[hoika]

Hallo,
was passiert, wenn du das Programm im Debugmodus ohne IDE startest?

[Uwe Raabe]

Zitat von jaenicke:

Vor allem Breakpoints mit Bedingung verlangsamen den Prozess extrem.

...und Watch-Expressions...

[Uwe Raabe]

Ich tippe aber doch auf die Exceptions, denn die werden bei StrToIntDef erst gar nicht geworfen. Vermutlich sind die EConvertError Exceptions in der IDE ausgeblendet, sonst würden die ja auffallen.

[BavDev]

Hallo,

@hoika: Debug-Modus ohne IDE kenne ich nicht.... Ich debugge immer von der IDE aus.

@Uwe Raabe:
Ich bin natürlich inzwischen schon wieder ganz woanders... Kann mich nicht erinnern, was genau gestellt war. Ich denke, ich hatte keine Breakpoints und keine Variablen bei diesem Test. Was ich sicher weiß: gleiche Voraussetzungen, einfach StrToInt durch StrToIntDef ersetzt, und es war schneller. Im Übrigen hatte ich auch mit StrToIntDef die gleichen Exceptions! Weil der Code war so:
try
i:=StrToInt(Text);
except
i:=MeinFehlerCode;
end;
(dauert 1:21 min)
bzw. neu
try
i:=StrToIntDef(Text,-1);
if i<0 then abort;
except
i:=MeinFehlerCode;
end;
(dauert 3 sek)

Das ist nur vereinfacht, zwischen try...except steht noch mehr, was einen Fehler werfen kann. Und die Fehlercodes werden entsprechend gesetzt.

Also es gibt keine zuverlässige Ursache?
Soll mir jetzt recht sein. Es reicht mir, wenn das Endprodukt sich "normal" verhält.

[Uwe Raabe]

Ein Abort erzeugt zwar auch eine Exception, die aber im weiteren Verlauf ignoriert wird und somit in der IDE nicht aufpoppt. Insofern kann man diesen Code

Delphi-Quellcode:

try
  i:=StrToIntDef(Text,-1);
  if i<0 then abort;
except
  i:=MeinFehlerCode;
end;

auch einfach so schreiben

Delphi-Quellcode:

  i:=StrToIntDef(Text, MeinFehlerCode);

[BavDev]

Uwe,
das ist mir schon klar, aber in diesem Zusammenhang nicht machbar.
Wie ich schon geschrieben hatte, passiert zwischen Try und except noch einiges andere, was Fehler verursachen könnte, und zwischen Except und End werden die einheitlich behandelt.
Und Dein Vorschlag geht schon deswegen nicht, weil die Fehlercodes sind Zahlen von 0 bis X, anhand derer ich den Fehlerort bestimme für die Weiterbehandlung, z.B. eine gezielte Fehlermeldung. Ein solcher Code kann aber auch ein gültiges Ergebnis von StrToIntDef sein.
Nix für ungut...