Performance des Silent-Operators und session_status()
So, heute gibts erneut eine digitale Version von zwei PHP-Magazin-Artikeln, die ich Anfang des Jahres verfasst habe. Beide sind in der goldenen Ausgabe zur neuen PHP Version 5.4 erschienen.
Der erste Artikel (PDF) untersucht die Änderungen am Silent-Operator @ (auch Fehler-Kontroll-Operator oder „Shut up“ Operator genannt), den man vor Ausdrücke schreiben kann um Warnungen zu unterdrücken. Mit 5.4 wurde die Performance verbessert wenn er in großer Anzahl, sprich innerhalb von Schleifen, genutzt wurde. Auch macht der Artikel noch mal klar dass er wenn möglich nicht genutzt werden sollte, denn selbst das Schreiben in das PHP ErrorLog kostet Zeit, die man sich in den meisten Fällen sparen kann. Im Artikel werden unter anderem die Einsatzgebiete, die Scream-Extension und Benchmarks betrachtet.
Der zweite Artikel (PDF) ist ein sehr kurzer, und es wird in wenigen Absätzen die neue Funktion session_status() vorgestellt. Ein kleines Beispiel verdeutlicht die Nutzung, die anhand des Manuals vielleicht nicht direkt erkennbar ist.
Ich muss gestehen, der Beitrag zum „@“ war mir leider zu wenig aussagekräftig.
b3nl
4 Dez 12 at 16:37
@b3nl Was hättest du dir im Artikel noch gewünscht an Infos bzw. Benchmarks? Was hättest du gern näher beleuchtet gesehen, welche Fragen hast du eventuell noch? Vielleicht kann ich das ja hier nachreichen.
Michael Kliewe
4 Dez 12 at 16:40
Ich hätte mir gewünscht, hätte es endlich alle Infos dazu an einer Stelle gegeben. Dazu fehlt mir z.B. der Vergleich, wie sich die Performance auch im Hinblick „nutze ich lieber @ oder array_key_exists o.Ä.“ auswirkt.
b3nl
4 Dez 12 at 16:45
@b3nl Das hätte man sicher noch überprüfen können, wobei sich dieser Artikel auf die Verminderung der Performanceeinbußen in der neuen PHP 5.4 Version konzentriert hat.
Es ging also weniger darum den Einsatz von @ gegenüber anderen Befehlen zu vergleichen (@ kann man vor so ziemlich alles setzen, mit was will man da genau vergleichen?), sondern eher die neue PHP-Version 5.4 zu pushen und zu zeigen dass es schneller geworden ist, man den @-Operator aber insgesamt so wenig wie möglich nutzen sollte.
In deinem speziellen Fall würde ich immer den Weg wählen, kein @ zu nutzen allein um besser debuggen zu können und Fehler einfacher finden zu können.
Beispiel:
$array1 = array('a' => 'alpha');
if (array_key_exists('a', $array1)) {
echo 'drin 1';
}
$array2 = array('a' => 'alpha');
if (@$array2['a'] !== null) {
echo 'drin 2';
}
Würden die beiden Fälle ungefähr so aussehen? Ich würde IMMER den ersten bevorzugen, selbst wenn er ein paar Prozent langsamer ist. Denn die zweite if-Abfrage bietet 2 Probleme:
– Was passiert wenn im Array statt ‚alpha‘ der Wert null im Array steht, dann hat man einen klassischen Bug.
– Was passiert wenn man die Variable falsch schreibt, statt $array2 würde man $array schreiben. PHP gibt keine Notice aus („Undefined variable: array“), und man sucht eventuell länger nach dem Fehler. Vertippt man sich in der ersten if-Abfrage und schreibt statt $array1 nur $array, dann gibt es eine Notice, und der Fehler ist schnell gefunden.
Fehlerunterdrückung sollte immer als letztes Mittel gewählt werden, denn wie im Artikel zu lesen, der Einsatz bedeutet PHP-intern das selbe wie error_reporting temporär auf 0 zu setzen (kostet Performance), außerdem wird bei einem auftretenden Fehler die Fehlerausgabe zwar unterdrückt, aber PHP-intern wird der Fehlerbehandlungscode trotzdem aufgerufen, das alles kostet Performance, meistens mehr als die saubere Lösung.
Wenn du Lust hast kannst du gern mal beides untersuchen, dann veröffentlichen wir hier im Blog die Ergebnisse. Oder du fragst das PHPMagazin ob die Interesse daran haben, das Thema performancetechnisch noch weiter zu beleuchten, könnte ich mir auch gut vorstellen.
Michael Kliewe
4 Dez 12 at 17:10
Aber nun stell Dir mal vor, Du liest diesen Artikel und benutzt NIE(!) das „@“. Dann ist dieser Artikel uninteressant. Übertragen sogar noch. Du möchtest sowohl performant, als auch „stilsicher“ als auch mit so wenig Code wie möglich arbeiten. Dich stört eigentlich andauernd, die manchmal eigentlich unnötige Funktions-Kontrolle zu schreiben, aber weißt von früher, dass diese irgendwie genauso schnell durchlaufen, wie das „@“ davor zu schreiben. (Um auf Dein Debugging-Beispiel einzugehen – wie bei Singletons auch – man muss das Ding schon korrekt wissen einzusetzen) Dann bleibst Du lieber bei der zusätzlichen Schreibarbeit. Nun mit PHP 5.4 könnte @ aber so schnell geworden sein, dass sich die zusätzliche Funktion in Deiner persönlichen Kosten-Nutzen-Abwägung nicht mehr lohnt. Das erfährt man aber nicht. Wäre also cool gewesen, hätte es diese Information vielleicht auch gegeben. (Selber messen kann ja jeder, dokumentieren wird aber blöd 😉 )
b3nl
4 Dez 12 at 17:27
Wobei ich leider auch so viel Programmierer kenne, denen es egal zu sein scheint, ob man eine Notice o.Ä. verursacht, da kann man nicht of genug erwähnen, was das zur Folge hat, von daher, danke für die Arbeit mal zu messen! 🙂
b3nl
4 Dez 12 at 17:35
Netter Artikel, besonders ein anderer Artikel von euch “
PHP in_array() die Performance-Bremse“ war für mich besonders wicht, da ich genau damit gerade arbeite und eine klasse erstellen wollte.
Mfg
Andy
7 Dez 12 at 08:19