Codeoptimierung lieber abschalten

[Sherlock]

FUD.

Sherlock

[himitsu]

Ja, es kann natürlich sein, dass die Optimierung irgendwo einen Bug hat
und dann doch dadurch etwas kapput geht.

"vorübergehend" kann man dann die Optimierung global oder besser nur lokal abschalten
und wendet sich dann dann an den Support -> quality.embarcadero.com .

Aber auch kann es ein Bug in Funktionen von Delphi sein, also RTL, VCL, usw. (wäre nicht das erste Mal), wo man dann eben auf andere Funktionen ausweichen könnte.



So lange es keinen halbwegs reproduzierbaren Testfall gibt, oder jemand überhaupt erstmal verrät, was eigentlich das Problem sein soll, kann aber schlecht irgendjemand eine Lösung finden.

Zitat:

Von daher meine Empfehlung: Die Codeoptimierung sollte immer deaktiviert sein.

Grundsätzlich, wie bereits mehrfach gesagt wurde:
NEIN

[dummzeuch]

Ich hatte das definitiv schon mehrfach, dass ich für einige Codezeilen die Optimierung ausschalten musste, weil der Compiler sonst fehlerhaften Code erzeugte. Das war reproduzierbar:

1. Debug-Build ohne Optimierung: Kein Fehler
2. Release-Build mit Optimierung: Fehler (z.B. Access Violation)
3. Release-Build mit Optimierung aber an einer bestimmten Stelle ausgeschaltet: Kein Fehler

Solche Fälle hatte ich bei Delphi 2006, 2007, XE2 und Delphi 10.2, wenn auch nicht notwendigerweise an denselben Code-Stellen.

Da ich Delphi 11 so gut wie nicht benutze, kann ich dazu nichts sagen.

Ich habe keine Bugreports geschrieben, da es sich nie um die aktuelle Delphi-Version handelte und meiner Erfahrung nach Bugreports für ältere Versionen einfach ignoriert werden. Keiner prüft, ob der Fehler bei der aktuellen Version vielleicht auch noch auftritt.

[jaenicke]

Zitat von dummzeuch:

Ich hatte das definitiv schon mehrfach, dass ich für einige Codezeilen die Optimierung ausschalten musste, weil der Compiler sonst fehlerhaften Code erzeugte. Das war reproduzierbar:

Solche Fälle habe ich schon mehrfach zugetragen bekommen. In den meisten Fällen zeigte sich in der Analyse des generierten Assemblercodes aber, dass der generierte Code korrekt war, nur wurden z.B. Variablen anders initialisiert. Solche und andere ähnliche Effekte führten dann zu den Problemen. Bevor es eine entsprechende Warnung gab, gab es z.B. auch Fälle, in denen jemand nach dem Ende der Schleife noch auf die Schleifenvariable zugegriffen hatte, diese mit Optimierung aber schon überschrieben war.

Ein paarmal waren es aber echte Compilerprobleme, die aber alle schnell behoben wurden, und auch alle die jeweils aktuelle Version betrafen.

[himitsu]

Zitat von jaenicke:

nach dem Ende der Schleife noch auf die Schleifenvariable zugegriffen hatte

Da hat der Compiler aber auch das Recht jemanden für zu bestrafen.

Bei Schleifen ist es schön, dass es nun die Inlinevariablen gibt.
Da kann man danach garnicht erst auf soeine blöde Idee kommen.

Delphi-Quellcode:

for var i: Byte := 0 to 123 do
for var i := 0 to 123 do
for var S in SL do
...

Jo, auch zwinschen Platformen und sogar zwischen Win32 und Win64 gibt es solche Problemchen.
Wo z.B. Result plötzlich "null" ist, wenn man es vergessen hat,
oder eben wo Variablen unterschiedliche "Initial"-Werte haben, jenachdem ob sie auf dem Stack oder in den Registern liegen, bzw. ob sie über die ganze Funktion oder nur den genutzen Zeitraum vorhanden sind usw.



Ebenso, wie bei gemangten Results, wäre es bei Schleifen gut, wenn nach dem Ende der Compiler "vergessen" würde, dass die Variable "eigentlich" schon initialisiert ist.
Dann gäbe es bei nachfolgenden Lesezugriffen auch eine entsprechende Warnung.