[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