[php] Optimierung durch Verzicht auf OOP war: [php] Ideales System?

[Ulf Wendel]

André Temme wrote:
> 
> Ulf Wendel schrieb:
> [...]
> > :) Application Server Diskussion. Kannst Du die Applikationen profilen?
> > Ist es wirklich der DB Zugriff, der Dich umbringt? Verzichtet die
> > Software bereits auf OOP (10-30%)? Nach den Erzählungen von Baerli gehe
> 
> Der Verzicht auf Objektorientierung bringt Geschwindigkeitsvorteile?
> Weil der Interpretor weniger zu tun hat? Wie sieht das dann bei
> (Zend-)compiliertem Code aus, bleibt da der Geschwindigkeitsnachteil
> (proportional?)

Es gibt eine ganze Reihe kleiner Tricks und Kniffe, welche die letzten
paar Prozent Laufzeit aus einem Code kitzeln. Eine Optimierung lohnt
sich aber nur dann, wenn der zugrundelegende Algorithmus bereits die
optimale Form erreicht hat. Generell sind keine wesentlichen Gewinne zu
beobachten. Alles was da an Zahlen geistert - auch von meiner Seite aus
- muß stark in Relation zur Gesamtlaufzeit gesetzt werden. PHP 4
versprach uns den Faktor 100, gemerkt habe ich nur -30% - +80%.

PHP hat keinerlei Optimierung für objektorientierten Code. Dieser ist
daher grundsätzlich langsamer als prozeduraler Code. Wenn sich nicht
viel getan hat, behandelt PHP ein Objekt immer noch wie ein Array -
diese Implementierung stammt nicht gerade aus dem Lehrbuch für
Compilerbau. Wäre der OO Support in PHP beispielhaft implementiert,
würde sich in der Praxis kein Geschwindigkeitsunterschied zeigen. Der
Overhead kann bei einer optimalen Implementierung auf wenige Operationen
begrenzt werden.

Zend hat keinen Compiler im Angebot, es gibt nur einen Encoder und einen
Optimizer. Der Optimizer versucht bei jeden Durchlauf kleinste
Optimierungen vorzunehmen, wobei ich kaum einen Effekt messen kann. Das
Hash-Test-Programm PHPDoc zeigt sich gänzlich unbeeindruckt von den
Optimierungsversuchen. Der Zend Encoder überführt den Klartext
Programmcode in eine dem internen Zend Byte Code ähnliche Form. Diese
kann schneller von der Zend Engine gelesen werden. Natürlich versucht
der Encoder noch an der einen oder anderen Stelle zu optimieren, aber
das ist nicht seine Hauptaufgabe und Zend verspricht auch keine
Leistungen in diesem Bereich. Zumindest die frühen Versionen sollen noch
einen Hinweis enthalten haben, das mit Encoder die Ausführungsdauer
sogar steigen kann, die Geschwindigkeit sinkt.

Wer unbedingt das letzte rausholen will der greift sich PEAR::Benchmark
und fangt an zu profilen und Handoptimierungen vorzunehmen. Dabei werden
Dinge rauskommen wie:

 - $string[0] statt substr($string, 0, 1)
 - strpos("foo") statt "foo" == substr($string, 0, 3)
 - nie ereg_*, immer preg_*
 - bei kleinen Hashes: foreach, bei großen reset/while/list/each
 - nie pass by reference außer bei Objekten
 - verzichte auf OO, Hashzugriffe sind schneller als Zugriffe auf
Objektvariablen
 - ...

Wirklich anraten seinen Code zu verstümmeln, kann ich jedoch nicht. Mit
der nächsten Zend-Engine kann sich das Blatt schon komplett geändert
haben. Auch wenn die Zimttüten es nicht glauben, auch Zeev hat einen
Blick für das, was PHP noch fehlt.

Heute sind die üblichen Antworten auf Speed Probleme jedenfalls nicht
die Handoptimierung des Codes. Urheber des Threads durfte ich jedoch
davon ausgehen, daß:

 - die DB optimal mit Indizes versorgt ist
 - die Sktipte klein und effektiv sind
 - eine Modulversion benutzt wird
 - nicht für 200 Datensätze ein Oracle benutzt wird
 - nicht alle 30 Sekunden ein Skript eine Ticker aktualisiert
 - keine Frames aus einem Request x Prozesse erzeugen
 - das Netz kein Nadelöhr ist
 - optimale Hardware vorliegt
 - die Klassenbiliothek als Extension vorliegt
 - Load Balancing über DNS gemacht wird
 - ...

Danach darf man langsam anfangen, in die Trickkiste der Verzweiflung zu
greifen und den Strohhalm Handoptimierung zu präsentieren.

Ulf