In der Tat, diese Zeile PHP bedarf einer Erklärung.
-
Nachtwächter
Kommentare
Kommentieren
In der Archivversion kann nicht kommentiert werden.
In der Tat, diese Zeile PHP bedarf einer Erklärung.
In der Archivversion kann nicht kommentiert werden.
tux. am 7.12.2011 um 02:20
Warum? Valider Code!
Nachtwächter am 7.12.2011 um 02:36
struct quax a;
*((int *) (((char *) &a) + offsetof (struct quax, quux))) = a.quux;
Nicht mal eine Warnung…
tux. am 7.12.2011 um 02:40
Aber verständlich! Wer es nicht versteht, sollte das Programmieren lassen.
Nachtwächter am 7.12.2011 um 02:41
Der blöde Compiler macht mal wieder genau das, was man ihm sagt und erzeugt folgenden Code aus einer Anweisung, die keine Auswirkung hat:
lea 0×10(%esp),%eax
add $0xc,%eax
mov 0×1c(%esp),%edx
mov %edx,(%eax)
Aber schon mit der Option -O2 erkennt er es und optimiert die Anweisung völlig weg.
tux. am 7.12.2011 um 02:51
Warum optimieren Compiler eigentlich nicht per default?
Nachtwächter am 7.12.2011 um 03:09
Gute Frage. Die Rechenleistung hätten heute auch »kleine« Maschinen, so dass die Übersetzungszeit nicht allzu fies explodieren würde. Jedenfalls nicht in diesem portablen Makroassembler namens C bei »normalen« Optimierungen; im postinkrementierten C sieht das schon wieder ganz anders aus.
Ein guter Grund ist die Möglichkeit, den Code im Debugger noch verstehen zu können. Bei vielen Optimierungen ist es nicht mehr leicht möglich, das Compilat eindeutlich zu einem Statement zuzuordnen. Meine Zeile mit der kompliziert formulierten Zuweisung einer Strukturkomponente auf sich selbst ist schon ein Beispiel, die wird beim Optimieren einfach weggeknetet, weil sie keine Auswirkung hat. Eine andere Optimierung ist das »Ausrollen« von Schleifen mit kurzem Schleifenkörper und einer konstanten Anzahl Durchläufe; die Anweisungen werden einfach hintereinander weg geschrieben, um den Overhead fürs Inkrementieren und Testen der Schleifen einzusparen. Bei ganz fiesen Optimierungen wird sogar die Reihenfolge der Anweisungen geändert, wenn sich dadurch besserer Code erzeugen lässt, und so etwas habe ich schon in den frühen Neunzigern mit dem SAS-Compiler fürn Amiga erlebt. Eine Debugger-Sitzung mit derartigem Code ist bestimmt eine gute Extraportion Kopfschmerz…
Viele Optimierungen haben auch eine in manchen Situationen unerwünschte Nebenwirkung: Sie blähen das Compilat auf. Heute sieht niemand mehr Speicher als eine kritische Ressource an (so wie das unter MS/DOS der Fall war). Der GNU-Compiler kennt die Option mit -OS, die nur solche Optimierungen durchführt, die nicht zu einer Aufblähung des erzeugten Codes führen.
Aber alles das ist kein Argument. Was spricht dagegen, dass man beim Proggen einfach eine spezielle Ich-will-das-Zeug-debuggen-können-Option setzt und sie fürs fertige Programm dann weglässt, weil man das standardmäßig eben nicht will? Eigentlich nichts… außer vielleicht die Gewohnheit, die sich seit den frühen Siebziger Jahren eingeschlichen hat.
Und solchen Gewohnheiten haben wir ja so viele lustige Dinge zu verdanken. Zum Beispiel die Shell-Syntax.
tux. am 7.12.2011 um 03:53
Ach, das ist eine um sich greifende Unart: »Wir haben viel Speicher, also belegen wir ihn auch.« Das wird einem irgendwann noch mal Leid tun. Ich habe gern ein paar GB »Puffer« im Speicher. Die Kiste hier hat acht Gigabyte RAM, ich möchte trotzdem nicht, dass ein einziger Prozess die Hälfte davon frisst. Erfahrungen.
fritz the cat am 7.12.2011 um 10:05
hi,
»[…]Was spricht dagegen, dass man beim Proggen einfach eine spezielle Ich-will-das-Zeug-debuggen-können-Option setzt und sie fürs fertige Programm dann weglässt[…]«
ich progge aktuell mit flash/flex/air und da ist das so, dass man eine spezielle debug-version hat und später dann ein release-build macht (das u.a. auch schneller läuft).
bin bei anderen umgebungen nicht aktuell, aber würde mich schon sehr verwundern, wenn man das nicht auch so macht.
Nachtwächter am 7.12.2011 um 15:59
Stimmt, in den meisten IDEs, die ich kennengelernt habe, stellte es sich so dar. Ich bin halt immer noch ein Freund des (meist handgeschriebenen) Makefile und kenne daher die Optionen beim Aufruf des Compilers. Und aus dieser Sicht wird standardmäßig nicht optimiert.
Wer ganz besonders irre ist (oder jedes Fitzelchen Performance braucht), kann die Optimierungen noch viel feiner steuern. Es gibt gefühlte 200 Optionen für jede verdammte Optimierung, und um die sinnvoll einzusetzen, muss man sie auch verstehen. Zum Glück braucht das kaum jemand.
Wurstauge am 8.12.2011 um 11:14
if (statusIsNotValid.compareTo( Boolean.FALSE ) != 0) skipValidation = false;
SvOlli am 11.11.2012 um 14:54
Nachdem ich das hier gelesen habe wäre ich mir nicht mal so sicher, ob der PHP-Code wirklich ohne Auswirkungen auf das Programm ist:
http://me.veekun.com/blog/2012/04/09/php-a -fractal-of-bad-design/