Kategorien
Mikro-Optimierung
Nachdem wir wohl alle gestern den ganzen Tag mit PHP 5.3 verbracht haben, wollen wir heute wieder den Ernst des Lebens zelebrieren und mal wieder versuchen was zu lernen. Da ich gestern gefragt wurde, ob ich nicht wieder öfters was über Softwaretechnik oder Architektur schreiben könnte, hab ich mir mal die meine letzten Beiträge angeschaut und da fiel mir echt auf, dass die letzten Themen eher so allgemeines „Bla Bla“ waren. Das liegt aber nicht dran, dass ich nicht mehr gerne was über die Tiefen der Softwareentwicklung schreiben will, sondern dass meine Arbeitstage zur Zeit relativ anstrengend sind und nach so einem Tag schreiben sich die seichteren Themen doch einfacher.
Heute geht’s um ein Thema, dass zur Zeit häufiger angesprochen wird. Mikro-Optimierung. Sogar google hat sich in einem Posting drüber ausgelassen und das ging meiner Meinung mal wieder vollkommen in die Hose. Vielleicht erst mal ein Beispiel für Mikro-Optimierung, damit ihr wisst, über was ich rede.
Vor kurzen wurde ich in ein gespräch involviert, in dem drüber diskutiert wurde, ob man lieber print oder echo verwenden soll. Um es noch weiter zu treiben könnte man noch rausfinden, ob der String, den ich per echo ausgeben will über Punkt oder Komma konkateniere. Echo hat einen Geschwindigkeitsvorteil gegenüber Print (oder andersrum). Der ist aber so gering, dass sogar jede Diskussion um dieses Thema teuer ist, als der spätere Benefit. Entwicklern vorzuschreiben, was zu zu verwenden haben, würde den Programmierfluß eines PHPlers durcheinanderbringen und somit eher schaden. Wenn ich mein Leben lang echo verwendet habe, dann sollte ich es auch weiterhin verwenden.
Solche Optimierungen nachträglich einzuführen, ist natürlich noch viel schwachsinniger. Arbeitet lieber am Caching oder nehmt euch einen Profiler zur Hand und sucht die Stellen, die wirklich Optimierung brauchen. Aber auch nur, wenn sie Optimierung benötigen. Ich habe zum Beispiel auch erst einen WordPress Cache eingeführt, als der Server in die Knie ging. Hätte ich es vorher gemacht, hätte ich mir eine neue Unbekannte geschaffen, die nicht sein muss. Das fällt aber unter das Thema „premature optimization“, dass wir auch bald mal angehen werden.
Wieder zurück zum eigentlichen Thema. Google beschreibt in seinem Artikel „Let’s make the Web faster“ eine Optimierungsschraube, die da heißt „Don’t copy variables for no reason„. Bedeutet, dass man nicht extra Werte zuweisen soll, wenn es nicht nötig ist.
$description = strip_tags($_POST['description']);
echo $description;In vielen Fällen stimmt das natürlich. Sobald ich aber an Übersichtlichkeit gewinnen kann, durch ein solches Kopieren, dann mache ich das. Der nächste Entwickler wird es mir danken. Übersichtlichkeit kann in vielen Fällen gewinnbringender sein, als Performance. Ist zumindest meine Erfahrung und auch die von Martin Fowler, wobei ich glaube, dass er sie vor mir hatte.
Tut euch also den Gefallen und wägt gut ab, an was ihr rumoptimiert. Das erste Langnersche Gesetz der PHP Entwicklung könnte also „Wartbarkeit vor Mikro-Optimierung“ lauten.
Anders gesagt, Mikro-Optimierung macht nur Sinn, wenn es nötig ist und wenn es sich lohnt. Wenn man einen Quad-Core + 4GB Speicher hat für eine kleine Homepage, ist es nicht nötig über soetwas nachzudenken. Lohnen wird es sich bei ein paar hundert oder tausend Zeilen wahrscheinlich auch nicht.
Hat man jedoch zeitkritische oder sehr gut besuchte Systeme, lohnt sich natürlich zuerst das Profilen, um dann zu optimieren. Meine Erfahrung ist jedoch, dass zu 99% der Wurm in umfangreicheren Algorithmen, Schleifen oder nicht optimierten SQL-Queries sitzt.
Meiner Meinung nach ist Mikro-Optimierung eine Sache, die niemand braucht. Ich habe mal gelernt: Solange man ein Performance-Problem mit etwas mehr Hardware lösen kann, sollte man das tun, bei den niedrigen Hardwarepreisen und den hohen Stundenlöhnen die wir haben.
Gerade kopieren bringt _keine_ negative Performance, da die Zend-Engine Copy-On-Write kann. Kurz gesprochen: Es wird erst etwas geschrieben, wenn in der neuen Variable etwas geaendert wird – bis dahin verweisen alle Variablen auf den selben Inhalt.
Siehe http://talks.php.net/index.php/Internals
@Kore: wieder was dazugelernt. Danke.
Die Antwort auf Googles Mirco-Optimirungs Tipps zu PHP kann man auch hier
http://groups.google.com/group/make-the-web-faster/browse_thread/thread/ddfbe82dd80408cc nachlesen. Da wird auch das Copy-On-Write erwähnt.
Also Mikro-Optimierung lohnt sich aus meiner Sicht eigentlich nur bei diversen for/foreach Schleifen, um spürbar/messbar mehr Performance rauszuholen. Notfalls muss man allerdings dann auch mal das ganze per Refactoring umbauen, wenn man selbst oder ein anderer Entwickler sich da völlig verrannt hat.
Vor ein paar Wochen hatte ich da auch einen Fall, eine foreach-Schleife über 400 Zeilen benötigte in PHP 8 Sekunden. Nach einer Stunde studieren des Quellcodes, den ich nichtmal verstehen konnte, hab ich mich dann dazu entschlossen, das ganze neu zu machen. Am Ende hab ich das ganze von ca. 2000 Zeilen PHP Code im Controller und nochmals soviel Zeilen in der View auf gut ein drittel kürzen können. Die ganze Seite brauchte dann statt 10 Sekunden nur noch 1,4 Sekunden bei vielen Daten und ca. 500ms bei geringen Daten – damit kann ich erstmal gut Leben 😉
„Normalerweise“ könnte das, trotz copy-on-write, etwas kosten – das label, das auf den Container zeigt, muss ja irgendwo gespeichert werden. In diesem Fall is dies aber ein „cached variable“ register und nutzt da quasi ein beim kompilieren reserviertes register für das label so dass das nichtmal in der Symboltabelle ankommt (wo der hashlookup _relativ_ langsam wäre)
Aber der gesamte Artikel is voll von non-sense. Bitte nicht ernst nehmen. Optimiert eure Datenbank und euere Queries und ihr gewinnt deutlich mehr als durch alle tipps in diesem Artikel zusammen und wen es dann immenroch drückt is neue Hardware (natürlich von Sun :-D) günstiger als die Arbeitszeit für diese optimierungen und die Pflege – zumla das gesparrte % meist eh durch neue User aufgefressen wird.
(Performancegewinn von 1% kann für Leute wie Facebook oder Yahoo interessant sein – da geht es dann darum „braucht die App ein Rechenzentrum mehr oder weniger“ für normale Anwender gibt es da ganz andere Faktoren…)
Ich würde mich anschliessen, dass Übersichtlichkeit immer vor Optimierung kommt. Deswegen bin ich auch starker Befürworter von ORM-Frameworks, weil dadurch ein „Fremdkörper“ (weitestgehend) aus dem Quelltext eliminiert wird und so die Lesbarkeit extrem verbessert wird.
@dennis becker Das war dann aber auch eher schon Makro-Optimierung, oder? 😉
Ich denke Mikrooptimierung macht eigentlich nur als vorrausschauende Maßnahme Sinn.
Wenn ich neuen Code schreibe, und mich zuvor mit Microoptimierung beschäftigt habe, schreibe ich sauberen Code im Sinne der Microoptimierung.
z.B.: Statt doublequoutes („) halt Singlequotes (‚) im Code zu verwenden kann schon Sinn machen, bei dingen wie print und echo muss ich ehrlich sagen das man’s auch echt übertreiben kann.
Nur nachträglich so was zu „optimieren“, ist vollkommener Schwachsinn.
Datenbankquerys und Schleifen klar das macht Sinn, aber nach solchen Dingen Performance zu suchen ist grober Unfug. Da kann ich ja gleich hergehen und meine Variablen, Methoden und Klassenbezeichner auf Foo und Bar tauschen, weil ja sonst größere Datenmengen beim Parsen anfallen… 😉
Und wenns um Performance geht gibts eh nur 3 Dinge: cachen, cachen und nochmals cachen.
@Alex: Hab ja geschrieben „Refactoring“ 😉 Mit Mikro-Optimierung wäre ich niemals ans Ziel gekommen 🙂
Ich muss grad mal dazu sagen, dass Johannes mit „gesamte Artikel is voll von non-sense“ den Google Artikel gemeint hat. Hoffe ich 😉
@Dennis: Alex meinte mAkro Optimierung 😉
Joa, ich denk am besten wärs wenn man einfach beim Lernen wenn man merkt, dass es zwei Möglichkeiten gibt, sich kurz überlegt oder nachguckt, was besser/schneller ist und das dann immer so macht.
Ich habe noch nie print benutzt und habe nie den wirklichen Sinn darin verstanden. Und ich habe mir angewöhnt immer Single-Quotes für Strings zu verwenden. (Wobei ich das gemacht habe weil ich diesem automatischen Erkennen nie ganz getraut habe: „Der erkennt das automatisch? Jedes mal wieder? Warum sag ich es ihm nicht einfach einmal?“)
Aber jetzt ein bestehendes Projekt komplett von echo auf print oder andersrum umstellen ist denk ich die beste Möglichkeit BT sinnlos zu verschleudern.
Auf jeden Fall denke ich sollte man sowas konsequent machen. Wenn ich in meinen Scripten eine Ausgabe suche weiß ich, dass ich nach „echo“ suchen muss. Wenn ich mischen würde, dann müsste ich nach „echo“ und „print“ suchen.
Was das Kopieren angeht: Man kann sich durch Kopieren aber auch die Übersichtlichkeit nehmen. Einfach weil man redundante Daten hat und dann besser nur noch die Kopie verwenden sollte. Wenn man gar keine Kopie hat, kann das nicht passieren.
Außerdem sind solche $foo=$_GET[‚foo‘]; (ohne strip_tags oder so) gefählich, weil ich $foo nicht mehr ansehe, dass es ein Eingabeparameter vom User ist. Wenn ich das gecheckt habe und mir sicher bin, dass es gültige Werte sind kann ich es auf $foo setzen. Aber vorher lasse ich es lieber im Superglobal, dann weiß ich auch: Das kommt von außen, damit musst du vorsichtig sein.
@Christopher Da muss ich dir recht geben, da gehört immer eine gewisse Konsistenz und Disziplin dazu.
Mit den Variablen von außen muss ich sowieso sagen, das einem hier MVC-Frameworks schon viel abnehmen sollten (Ein User-Input Objekt o.Ä.) hier wäre Microoptimierung schon grob fahrlässig und gefährlich (SQL-Injection usw.)
Deswegen kann ich dir mit „im Supergolbal“ belassen nur bedingt zustimmen.
@ Manuel: Ja wenn ich ein MVC Framework nehme, dann macht das des ja für mich. Aber dann macht Mikrooptimierung wirklich überhaupt keinen Sinn mehr. Dann sollte ich besser ein schlankes Framework verwenden (z.B: Kohana) anstatt in den Krümeln zu suchen.