Contao und Referenzen in PHP - Performance?

[Toflar]

Hallo allerseits!

Ich bin auf der Suche nach jemandem, der regelmässig mal Performance-Tests macht und eine geeignete Entwicklungsumgebung besitzt.

Ich habe vor einigen Wochen mal einen interessanten Artikel gelesen. Geschrieben hat der Artikel Johannes Schlüter, der Release-Manager von PHP 5.3.
Den Artikel findet ihr hier: http://schlueters.de/blog/archives/1...eferences.html

Momentan werden in TL/Contao ja alle Sprach-Arrays mit Referenz übergeben und ich frage mich, ob wir Contao noch performanter machen könnten, wenn wir die Referenzen entfernen würden.

Einfach mal ein einfaches "Suchen und ersetzen" mit "&$GLOBALS" und "$GLOBALS" machen und dann mal gucken, ob PHP effektiv schneller interpretieren kann.

Wie seht ihr das? Meinungen? Tests? Kann jemand sowas testen? Jemand Erfahrung im Performance testen?

Bin mal gespannt auf's Resultat

[xtra]

Wenn man bei den Language strings nun die & entfernt, dann wird nix mehr tun..

Schliesslich wird hierdurch eine "klemmende" Referenz auf einen String gesetzt und nicht der String selbst gesetzt.
Probier es aus und denk nochmal dryber nach.

PS: im Allgemeinen hat er jedoch Recht, Referenzen sollten vermieden werden, sofern nicht zwingende Grynde dafyr sprechen (wie z.B. bei der Ybersetzung).

[leo]

Ich frage mich auch, wie viel langsamer die Verwendung von Referenzen ein Skript wohl macht. Das sollte doch im Bereich von Millisekunden liegen, oder? Zudem finde ich es ein bisschen extrem, Referenzen per se zu verteufeln. Klar, in PHP4 wurde das Feature sehr extensiv genutzt und vielen ist sicherlich die Umstellung auf PHP5 nicht leicht gefallen. Aber es soll auch Fälle geben, in denen Referenzen ein hilfreiches und somit durchaus berechtigtest Instrument sind

[xtra]

Daher mein PS, es gibt Faelle wo dies Sinn macht.
Aber generell kaempfen wir hier noch mit PHP4 Code wo diese schlichtweg keinen Sinn mehr machen.
Ebenso haengen, wie von dir gesagt, etliche ihrer alten Mentalitaet nach alles per se zu verreferenzieren.

Im allgemeinen gibt es jedoch viel groessere Bottlenecks die man eher angehen sollte.

[Toflar]

Wenn man bei den Language strings nun die & entfernt, dann wird nix mehr tun..

Schliesslich wird hierdurch eine "klemmende" Referenz auf einen String gesetzt und nicht der String selbst gesetzt.
Probier es aus und denk nochmal dryber nach.

Muss ich gucken ne Ich quetsch Dich dann wieder aus. Momentan kapier ich nämlich nicht ganz, was Du meinst, aber ohne Code geht das ja auch schlecht. Mal drüber schauen, wenn ich Zeit hab!

@leo: Wenn überhaupt Milisekunden. Denke auch nicht, dass es viel ausmacht. Aber man soll ja nichts unversucht lassen, um das System schnell zu halten

Ich hab im Grunde genommen nur nach "php references" gegoogelt und diesen Artikel gefunden und mir gedacht "hmm, vielleicht gibts da Optimierungspotenzial, wer weiss"

[backbone]

Nur mal zum Verständnis: Was passiert genau, wenn man die Übersetzungen nicht per Referenz anspricht? 1-2 Sätze reichen.

[xtra]

Nur mal zum Verständnis: Was passiert genau, wenn man die Übersetzungen nicht per Referenz anspricht? 1-2 Sätze reichen.

nur ein kleines Beispiel um das Problem zu beschreiben:

// Entspricht dem laden der lanugage files.
$GLOBALS['TL_LANG']['tl_proofofconcept']['langstr']='Test 1';
// entspricht dem laden der DCA (mit referenz)
$GLOBALS['TL_DCA']['tl_proofofconcept1']['fields']['langstr']['label']=&$GLOBALS['TL_LANG']['tl_proofofconcept']['langstr'];
// entspricht dem laden der DCA (ohne referenz)
$GLOBALS['TL_DCA']['tl_proofofconcept2']['fields']['langstr']['label']=$GLOBALS['TL_LANG']['tl_proofofconcept']['langstr'];

// nochmaliges Laden der language Dateien ggf. in einer anderen Sprache oder evtl. andere is ja nur proof of concept.
$GLOBALS['TL_LANG']['tl_proofofconcept']['langstr']='was ist passiert?';

// Nun haben wir:
$GLOBALS['TL_DCA']['tl_proofofconcept1']['fields']['langstr']['label']=='was ist passiert?';
// Und 
$GLOBALS['TL_DCA']['tl_proofofconcept2']['fields']['langstr']['label']=='Test 1'; 

Anmerkung am Rande: dca Dateien werden per include_once() importiert (und das ist auch aus gutem Grunde so). Die Sprachwerte koennen jedoch yberall wild vertauscht werden und ersetzen dank Referenz "dynamisch" die alten Werte in den DCA.

[andreas.schempp]

Ein ganz einfacher, wichtigerer Grund: Die Sprachdateien werden NACH dem DCA geladen. Ohne Referenz wären die Sprachlabels immer leer...

[andreas.schempp]

BSP doppelte Hochkomma statt einfachen. Besonders bei Query's im prepare() wird diesr Fehler seeehr oft und gerne gemacht. Ich glaube selbst im Core.

Was ist daran ein Fehler? Meinst du weil nach Variablen geparst wird?
Bei SQL-Queries verwende ich auch immer Hochkommas. Allerdings gerade bei Queries lässt sich sehr viel optimieren wenn für "sichere" Werte nicht prepare()->execute() genutzt wird...

[leo]

Interpolation kann man nun wirklich nicht als Bottleneck bezeichnen. Die Unterschiede liegen im Nanosekundenbereich

[xtra]

Interpolation kann man nun wirklich nicht als Bottleneck bezeichnen. Die Unterschiede liegen im Nanosekundenbereich

Das ist nun ein Punkt bei dem ich sogar bereit bin zu streiten.
Welchen Sinn macht Interpolation, wenn keine vorgenommen werden kann, weil nichts zum interpolieren vorhanden ist?

Fyr alle die nicht wissen worum es generell dabei geht ein paar links (englisch):
http://www.astahost.com/info.php/Php...ion_t4286.html
http://stackoverflow.com/questions/1...nation-in-php5

Die Zeit von etwa 2/3 bei concat ggyber interpolation kann ich bei mir bestaetigen (da bei einer Interpolierung intern ebenfalls eine concat vorgenommen wird ist dies auch wirklich verstaendlich).
Klar sind diese Zeiten im allgemeinen im ms Bereich und in real world Anwendungen recht klein, jedoch sind dies Zeitfresser die einfach nicht notwendig sind und mit minimalstem Aufwand ohne negative Seiteneffekte vermieden werden koennen (Zumindest bei literalen Strings bleibt der code genausogut lesbar wie ohne).
Die Aussage von Andreas ist jedoch ebenfalls genauso richtig, man kann durch concatenation und das Umgehen von prepare recht viel gewinnen, execute nichts zu tun hat ausser das Query "durchzuwinken".

Im Endeffekt waege ich immer ab, was im jeweiligen Falle die richtige Methode ist (nein, auch ich messe nicht jede Zeile in allen Varianten durch und nehme dann die, die gerade den Besten Benchmark bekommen hat ).
Ich denke, das sollte jeder Entwickler tun und deshalb tu ich es auch.

Ein groesseres Bottleneck koennte z.B. sein, dass die Singletons yberall mitgeschleift werden, egal ob gebraucht oder nicht. Doch dazu fehlen mir die Benchmarks, das ist nur ein subjektives Gefyhl.

Ich finde die Diskussion hier aber super, solche Dinge sollten wir auch alle auf der Contao DevCon in Stuttgart (Die sollte doch bei Jan steigen, oder?) besprechen.

Gruss
Chris

[leo]

Deswegen nutzen wir ja auch einfache Anführungszeichen als Standard. In SQL-Statements werden die einfachen Anführungszeichen aber bereits verwendet und ich schreibe lieber

$sql = "SELECT * FROM tl_user WHERE username='leo'"; 

anstatt

$sql = 'SELECT * FROM tl_user WHERE username=\'leo\''; 

Denn viele Backslashes nerven auf Dauer gewaltig, machen den Code unübersichtlicher und sind dadurch auch eine potentielle Fehlerquelle. Dasselbe gilt für HTML-Code (sofern er nicht sowieso in Templates ausgelagert ist).

$html = '<span class="info">Info</span>' 

anstatt

$html = "<span class=\"info\">Info</span>" 

solche Dinge sollten wir auch alle auf der Contao DevCon in Stuttgart besprechen

Wann wird die sein? Gibt es da schon konkrete Pläne?

[alex]

Ich finde die Diskussion hier aber super, solche Dinge sollten wir auch alle auf der Contao DevCon in Stuttgart (Die sollte doch bei Jan steigen, oder?) besprechen.

Wird da die "DevCon" mit dem "Usertreffen 2011" verwechselt ?
Interessant ist auch, dass der Ort "Stuttgart" auch schon fest steht....

[xtra]

Wird da die "DevCon" mit dem "Usertreffen 2011" verwechselt ?
Interessant ist auch, dass der Ort "Stuttgart" auch schon fest steht....

Nein wird sie nicht.
Dennoch hatten wir etwas derartiges bei der Schlussbesprechung auf dem TLUT10 in den Raum gestellt.
Weiterhin ist dies nicht zwingend sondern ein einfacher Vorschlag, da Jan Theofel von ETES freundlicherweise angeboten hatte, sich um Raeumlichkeiten zu kymmern.

Abschliessend ist die Zielgruppe der DevCon eine gaenzlich andere als die vom UT, da es um entwicklerspezifische Aspekte gehen soll und nicht so breitgefaechert wie auf dem UT.

Die Planungen hierzu haben aber noch nicht wirklich begonnen (zumindest soviel ich weiss), daher Ball flach halten und abwarten.
Erstmal muss 2.9 released werden.

Gruss
Chris

[backbone]

Ein groesseres Bottleneck koennte z.B. sein, dass die Singletons yberall mitgeschleift werden, egal ob gebraucht oder nicht. Doch dazu fehlen mir die Benchmarks, das ist nur ein subjektives Gefyhl.

Auch wenn ich bei dem Punkt nichts direkt zu dem Thema Performance sagen kann, ist es abgesehen davon, aus Sicht der objektorientierten Softwarearchitektur ziemlich fraglich, ob Referenzen auf Singletons mit öffentlichen getInstance()-Zugriffsmethoden irgendwoanders als im Singleton selbst (bzw. in der zugehörigen Manager-Klasse) gespeichert werden sollen.
mMn. sollte man diese Referenzen generell entfernen. Natürlich ist es etwas kürzer $this->Input als Input::getInstance() zu schreiben, aber das kann man verkraften. Zur Not könnte man dann auch eine "Accessor-Function" schreiben wie:

function Input() { return Input::getInstance(); };

oder von mir aus auch das Singleton in den GLOBALS abspeichern.
Da lazy-init auch nicht notwendig sein sollte (da eh fast alle Singletons, während initialize.php instanziiert werden), kann man auch direkt auf eine public static zugreifen (da aber leider kein "final" vorhanden ist, könnte man dies überschreiben).

Edit:
Die "Accessor-Function" sollte egtl. auch als Closure möglich sein? (Bin nicht sicher)
Das würde im Konstruktor der Singleton-Klasse dann ungefähr so aussehen:

class Input {
  private static $objInstance;
  private function __constructor(...) {
    function Input() {
      return self::$objInstance;
    };
  }
}