carrib

Hi!

Ich setze den Zend Optimizer seit einiger Zeit ein, habe mit Turck MMCache & Co. beschäftigt und mich interessiert die Funktionsweise (die Optimierungsschritte) dieser Accelerator sehr.

Hier und da gibt es immer Schnipsel mit Informationen darüber, wie man selber Code entsprechend eines Accelerators optimieren kann, jedoch leider noch keine, mir bekannte, gute Sammlung dieser Tipps.

Jepp, es könnte die Frage aufkommen "Wieso willst Du das wissen, wenn Du eh schon einen Accelerator verwendest?", soll aber im Keim erstickt werden. Nein, ich will das Rad nicht neu erfinden! Tatsächlich kann es in Unternehmen passieren, dass man am Versuch einen solchen einzusetzen scheitert, des weiteren frage ich mich, ob man trotz Accelerator selber noch etwas "rausholen" kann.

Bsp. der vorrangige Einsatz des Prä-Inkrementoperators (++$a) statt des Post-Inkrementoperators ($a++), da der erste schneller durch den Interpreter verarbeitet wird (bsp. ein einfacher Optimierungsschritt des Zend Optimizers).

Oder bsp. als kleiner Tuning-Tipp der vorrangige Einsatz von single-quoted Strings, da diese nicht geparst werden. Wobei ich mich hierbei Frage ob bsp. umfangreiche printf()-Anweisungen durch den Accelerator, sofern sinnvoll, durch entsprechende echo Anweisungen ersetzt werden,oder ob solche Optimierungen dem Anwender überlassen werden und man die Performance durch solche Maßnahmen trotz Accelerator noch verbessern kann (gut, der Einsatz von printf() ist hier Perlen vor die Säue, aber nur ein Beispiel).

Wird durch den Accelerator bsp. ein Output-Buffering durchgeführt und das Ergebnis nach der Ausführung komplett an den Client gesendet, obwohl im Script kein Output-Buffering verwendet wurde, oder werden die Daten trotzdem mit jedem echo & Co. ohne expliziten flush() an den Client geschickt?

Hat sich jemand schon ausführlicher mit Thema beschäftigt bzw. kann jemand eine Quelle mit ausführlicheren Informationen zu diesem Thema nennen?

Thx!

Mister Ad

Waq

Vollkommene Zeitverschwendung.
Wenn man sich an alle diese Sachen hält, bekommt man es vielleicht hin, dass die Applikation am Ende 2% schneller ist. Betonung auf vielleicht.

Wenn man einmal ein Profiling macht, die echten Performance-Probleme findet und dann entsprechend nach einer Lösung für diese sucht, wird die Applikation meist mindestens um den Faktor 2 schneller, kann aber auch deutlich mehr sein, je nach Art der Fehler die man findet. Und die findet man immer. Da braucht sich keiner was einzubilden, er wäre doch kein so schlechter Programmierer, selbst extrem gute Programmierer finden beim Profiling noch was, was die Applikation deutlich ausbremst.

Bei allem diesem Kleinscheiss, sollte man die Variante nehmen, die besser aussieht, wartbarer ist etc., denn davon hat man wirklich etwas.


Diese ganzen Kleinscheissoptimierungen sind sehr sinnvoll, wenn sie automatisiert vom Zend-Optimizer durchgeführt werden, wobei dieser ja auch mehr macht als das. Der sollte auch Invarianzen finden und wegoptimieren... hoffe ich zumindest mal. Den Quellcode kann man ja nicht ansehen
Dass die Acceleratoren diese Optimierungen nutzen liegt nur an einer Sache: Da sie PHP-Code nicht bei jeder Ausführung neu kompilieren, lohnt es sich, hinter die Kompilierung einen längeren und ausführlicheren Optimierungsvorgang zu hängen, der sonst stören würde.
Das ist aber für die Acceleratoren eigentlich nur Nebensache, den Geschwindigkeitsgewinn kommt fast ausschliesslich aus dem Bytecode-Caching.

__________________
mod = master of disaster