Codeoptimierung lieber abschalten

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

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

[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

[dummzeuch]

Zitat von 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...

Aber wir haben doch gerade von allen Seiten gehört, dass der Compiler beim Optimieren keine Fehler macht. Selbst mein Hinweis, dass ich solche Fehler schon mehrfach gesehen habe, wurde abgebügelt mit "das Problem war bestimmt in Deinem Code" (nicht dass das falsch wäre, schließlich war es mein Code, der optimiert wurde, ohne ihn wäre kein Fehler aufgetreten, aber es ist nicht hilfreich).

OK, ernsthaft: Das mache ich auch so, allerdings nicht durch ifdef im Sourcecode sondern durch Setzen der Option in der Release-Config. Das ifdef hat den Nachteil, dass es nicht so simpel ist, die Optimierung einzuschalten, weil man dafür den Sourcecode ändern muss.