Codeoptimierung lieber abschalten

[Michael Ebner]

In der Hilfe zu Delphi findet man zur Optimierung die folgenden Aussagen:

Zitat:

Die Direktive $O steuert die Codeoptimierung. Im Status {$O+} führt der Compiler eine Anzahl von Codeoptimierungen durch, indem er beispielsweise Variablen in CPU-Registern platziert, doppelte Teilausdrücke eliminiert und Induktionsvariablen generiert. Im Status {$O-} werden diese Optimierungen nicht durchgeführt.

Außer in bestimmten Testsituationen sollte die Codeoptimierung immer aktiviert sein. Die Optimierungen des Delphi-Compilers führen zu keinerlei Änderungen der Funktionsweise des Programms. Der Compiler führt also keine "unsicheren" Optimierungen durch, die die besondere Aufmerksamkeit des Programmierers erfordern.

Die Aussage, dass die Optimierung des Delphi-Compilers zu keinerlei Änderungen führen, entspricht nicht der Wahrheit. (Konkret Delphi 11, Update 1, kompiliert für WIN 32)

Das Bemerkenswerte daran: Das trat jetzt gerade nicht in einem Fall auf, in dem Timing-Geschichten oder so etwas $DINGE beeinflussen könnten, nicht um Threads, nicht um irgendwelche eingebundenen Bibliotheken, die möglicherweise sehr krude programmiert wurden. Sondern um simple String-Bearbeitung mit den Delphi-Standard-Units.

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

[Daniel]

hm. Kann ich in der Pauschalität nicht bestätigen. Man mag dem Delphi-Compiler einiges vorwerfen können, doch die klassischen String-Operationen hat er definitiv gut im Griff.
Kannst Du dies auf ein handhabbares Beispiel reduzieren?

[mjustin]

Zitat von Michael Ebner:

Das Bemerkenswerte daran: Das trat jetzt gerade nicht in einem Fall auf, in dem Timing-Geschichten oder so etwas $DINGE beeinflussen könnten, nicht um Threads, nicht um irgendwelche eingebundenen Bibliotheken, die möglicherweise sehr krude programmiert wurden. Sondern um simple String-Bearbeitung mit den Delphi-Standard-Units.

Kann dies in einem einfachen Code-Beispiel reproduziert werden?

Ich vermute, der Fehler wurde innerhalb einer bestehenden Anwendung beobachtet, die möglicherweise bereits Fehler enthält, die zu einem Seiteneffekt geführt haben.
Das ist in der Praxis leicht möglich, wenn z.B. Speicherkorruption ausgelöst wird, oder Speichermangel besteht.

[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.

[freimatz]

Zitat von mjustin:

Ich vermute, der Fehler wurde innerhalb einer bestehenden Anwendung beobachtet, die möglicherweise bereits Fehler enthält, die zu einem Seiteneffekt geführt haben.
Das ist in der Praxis leicht möglich, wenn z.B. Speicherkorruption ausgelöst wird, oder Speichermangel besteht.

Auch meine Meinung. Zu 99% macht der Compiler keinen Fehler.

[Benmik]

Zitat von freimatz:

Zu 99% macht der Compiler keinen Fehler.

1% Fehlerrate? Das wäre gigantisch.
Ich finde übrigens

Delphi-Quellcode:

{$IFDEF DEBUG}
  {$OPTIMIZATION OFF}
{$ENDIF}

praktisch.

[Andreas13]

Zitat von Benmik:

Delphi-Quellcode:

{$IFDEF DEBUG}
  {$OPTIMIZATION OFF}
{$ENDIF}

Ist das nicht zu riskant? Wir unterdrücken damit eventuelle Fehler im Debug-Modus, lassen sie jedoch in der endgültigen Release-Version zu...
Grüße, Andreas