Kategorien
Projektwerkstatt: Mikro-Optimierung
Jeder, der schon mal mit mir zusammengearbeitet hat, weiß, dass ich Optimierung hasse. Ich kann eine richtige Nervensäge sein und bin da auch rigoros. Ich glaube nämlich wirklich an die Regel, dass man nicht von Anfang an optimieren sollten, sondern erst dann, wenn das System zu langsam wird. Ich bin dann zwar häufig der Buh-Mann, aber damit muss ich leben. Dafür werden meine Projekten pünktlich fertig. Naja zumindest werden sie nicht aus dem Grund der Überoptimierung nicht fertig.
Da ich zu frühe Optimierung nicht mag, muss ich ja aus Prinzip schon Mikro-Optimierung hassen. Und so ist es natürlich auch. Es gibt so viele Artikel im Netz, die beschreiben, was passiert wenn man $i++ statt ++$i verwendet. Und irgendwie hört es nicht auf, dass diese Ideen verbreitet werden. Erst letzte Woche habe ich wieder so etwas gelesen und musste mit den Ohren schlackern. Jetzt könnte man hingehen und in jedem dieser Artikel einen Kommentar posten, dass der Autor doof ist und Salat kocht, eine Beleidigung der Mutter wäre sicherlich auch eine Option. Wir sind aber (meistens) erwachsen und wissen natürlich auch, dass das gar nichts bringt.
Wenn man es rein mathematisch betrachtet, dann haben sie ja auch recht die Optmierer. Wenn ich ein paar Millionen mal ++$i statt $i++ verwende, dann merkt man schon einen Unterschied. Jetzt also endlich zu meiner Idee. Man nimmt sich eine Standard-PHP-Applikation, wie WordPress und optimiert diese mit allen Tricks, die die Mikros so vorschlagen. Und dann schaut man, was passiert. Ich bin mir sicher, dass alle Optimierung im Rauschen untergeht. Ein $i++ wird eben doch nur 100 mal aufgerufen in einem Skriptdurchlauf und nicht ein paar Millionen.
Jedes mal, wenn wieder jemand eine besonders tolle Idee hat, wie man den Source-Code beschleunigt, könnte man sein Power-Wordpress anpassen. Ich bin mir sicher, dass man, wenn man eine Webseite um das ganze Thema rumbastelt da wirklich was erfolgreiches zaubern kann. Ich würde auf jeden Fall jedes mal wenn ich über einen solchen Artikel stolpere einen Link setzen.
Vielleicht wäre das auch mal ein Artikel fürs PHP-Magazin wert. Im ersten Teil beschreibt man wie geil Mikro-Optimierung ist und im zweiten wirft man die Thesen gegen die Realität und merkt wie man auf die Nase fällt. Ich schau mal ob man da was machen kann.
Ich sehe das etwas anders. Klar hast du Recht, dass die „Optimierungspotentiale“ sehr gering sind und viel zu oft als Allheilmittel gepriesen werden (was sie ja ganz klar nicht sind), aber dennoch gibt es hier ein paar Aspekete, die man berücksichtigen sollte.
Zum Einen ist es beispielsweise bei mir so, dass ich mir gewisse Dinge einfach angewöhnt habe. Somit stellen sie für mich keine wirkliche Optimierung mehr dar, sondern gehören einfach zu meinem ganz normalen Programmier-Alltag und ich achte schon gar nicht mehr explizit darauf, dass ich ++$i schreibe, sondern mache es einfach. Genau so ist es bei vielen anderen Kleinigkeiten, die man wohl normalerweise als Mikro-Optimierungen bezeichnen würde.
Des Weiteren finde ich Artikel über diese Dinge gut, da sie besonders Anfängern ins Bewusstsein rücken, wie Programmiersprachen aufgebaut sind und dass es eben doch manchmal eine Rolle spielen kann, wie man nun Dinge verwendet oder aufruft. Als ich damals zum ersten Mal von den Unterschieden zwischen ++$i und $i++ erfahren habe, habe ich mich erst mit dem Thema auseinandergesetzt, wie gewisse Funktionen überhaupt aufgebaut sind. Und es kann ja nichts schlechtes sein, Leuten durch solche Dinge die Motivation zu geben, sich mal mehr mit dem Hintergrund zu befassen.
Zum Schluss bin ich der Meinung: Wenn es nicht schadet, warum dann schlecht reden!? Es gibt immer wieder Dinge, über die in der Entwicklerszene viel diskutiert wird, oft auch zu viel. Warum also unbedingt die Mikro-Optimierungsmöglichkeiten auch schlecht reden? Klar kann man einwenden, dass die Performance-Verbesserungen so minimal sind, dass sie wahrscheinlich kaum etwas bringen. Aber schadet es deshalb jemandem diese Dinge zu verfolgen oder Artikel darüber zu verfassen?
@Tim: „Wenn es nicht schadet, warum dann schlecht reden!?“
Im Artikel ist genannt, wann das schlecht ist. Wenn bei einem Projekt die Ressourcen (Arbeitszeit) in die Mikro-Optimierung gesteckt werden und dann das Projekt nicht fertig wird, schadet das sehr wohl. Darum geht es sicherlich.
Interessant wäre auch folgende Frage: Welche Optimierungen nimmt der PHP-Interpreter vor? Wenn $i++ und ++$i als Statements (wie in for-Schleifen üblich) eingesetzt werden, gibt es vielleicht performancemäßig gar keinen Unterschied.
Mikro-Optimierung geht doch schon bei der Wahl der PHP-Software (WordPress, Joomla, Drupal usw.) bzw. des PHP-Frameworks los, wenn diese aufgrund der „Performance“ abgelehnt werden. Die Vorteile werden dagegen gar nicht beleuchtet, natürlich ist ein „eigenes“ Framework bzw. PHP4-Script-Code schneller, aber eben nur das.
@Tim
Um sinnvolle Dinge anzuwenden, dagegen sagt niemand was. Problematisch wird es dann wenn man etwas Sinnvolles liest und dieses sofort in dem eigenen Projekt anwenden will – koste es (Zeit & Aufwand) was es wolle.
Kann in großen Teilen Tim recht geben – wenn man sich eben bei Strings die Verwendung des Hochkommas zum eigenen Stil gemacht hat sehe ich da kein Problem drin. Schlimm wirds nur, wenn die Leute dann mit abenteuerlichen, alltagsfremden Konstruktionen daherkommen, von denen auch sonst niemand so recht weiß, was es damit jetzt auf sich hat – alles für die letzten 0,005%. Genannt sei da z.B. die Ersetzung von foreach durch abgefahrene Sachen wie while(list(…) = each(…)), wo man sich dann nur noch an den Kopf greift.
Sehr passendes Thema. Habe gerade am Wochenende „Pre-Inkrement“ und „Pre-Dekrement“ in ein Coding-Standards-Dokument aufgenommen.
Im einem Punkt möchte ich mich da meinem Vorredner Tim anschließen:
Es geht, in gewisser Weise, um Mikro-Optimierungen der beteiligten Entwickler!
Wenn ich doch von Anfang an die Wahl habe die Pre-Inkrement Variante zu schreiben, die lediglich ein kleines Umdenken, aber nicht sehr viel mehr Aufwand erfordert, dann sollte es sogar selbstverständlich sein, dass diese dann Verwendung findet.
Hier sollte man ggf. darüber nachdenken, die Entwickler im eigenen Team entsprechend zu sensibilisieren. Ich mache dies in allen meinen Teams.
@Nils
Ich gehe aber davon aus, dass du dich auf die Fälle beziehst, bei denen die Entwickler bis zum Abwinken am Code rumdoktorn. In diesem Fall gebe ich dir Recht, da der Aufwand in keiner Relation zum tatsächlichen Nutzen steht. Zumal die Gefahr besteht, nicht (rechtzeitig) fertig zu werden.
@David: Da redest du von unleserlichem Code, der ist natürlich schlecht, egal ob er optimiert oder nicht.
Also primär sollte man lesbaren Code schreiben. Und wenn der am Ende zu langsam sein sollte, dann kann man immer noch optimieren. Und hierbei sollte man dann auch einen Profiler benutzen. Dann findet man die Stellen, die zu langsam sind, oder die Optimierungspotential haben.
So aus dem Bauch heraus würde ich sagen, dass i++ oder ++i dann nicht auffallen wird 🙂
@Benjamin: Ich bin mir ziemlich sicher, dass die Unterscheidung von Pre- oder Post-Increment keine Performance-Unterschiede in eurem Code bringen werden.
In den meisten Fällen findet Optimierung in der Architektur statt und da geht es nunmal nicht um Code. Ich habe sicherlich nichts dagegen eine Methode, die tausende Mal aufgerufen wird zu mikro-optimieren, alles andere ist aber vergebene Liebesmühe.
Mir fällt dazu grad noch ein Punkt ein. Und zwar das Refactoring. Wenn ich Code neu schreiben möchte, der vom „gefühlten Standard“ abweicht, brauch ich länger, weil ich mich erstmal eindenken muss – etwa, ob das Pre-Inkrement hier lediglich aus performancegründen verwendet wurde oder ob sich dadurch eine Sinn-Änderung ergibt. Kann man auf die anderen Tipps ausweiten.
@Nils
Stimme ich vollkommen mit überein. Gerade im Bezug auf die richtige Architektur – ohne Frage.
Mit der Aufnahme in die Standards soll auch kein optimierter oder performanterer Code erreicht werden, sondern sauberer, standardisierter Code. Alles andere ist ein netter Nebeneffekt.
Die Ausgangssituation war die folgende:
Bei einer Review zur fortlaufenden Optimierung der Code-Qualität ist mir aufgefallen, dass ein Teil der Entwickler den Online aufzufindenen Versprechungen von bis zu 10% mehr Performance bei den Pre-Varianten anscheinend blind glauben schenkt.
Ich wurde mit (gefühlten) 60% Post und 40% Pre konfrontiert. Das fand ich unschön und forderte bei mir einen zusätzlichen Denkvorgang bei der Durchsicht. In meinen Augen unnötig.
Somit habe ich die Coding-Standards ergänzt. Die betroffenen Stellen werden sukzessive umgeschrieben und zukünftig gilt (sofern möglich) die Pre-Variante als Standard.
Wird bei mir unter „Optimierung im Sinne der Qualität mit nettem Nebeneffekt“ abgehandelt.
Der Quelltext ist nun mal die Basis einer Software und ich gelte sowieso als üßerst penibler Clean-Code-Fanatic – dazu stehe ich auch 😉
btw:
Hast du es mal mit einem Benchmark getestet?
Ich denke auch, dass ein Projekt unter zu viel Optimierung sehr schnell leiden kann. Deswegen versuche ich in der Implementierungsphase auch erstmal jegliche Optimierung auszublenden, es sei denn es handelt sich um eine Optimierung, die einen enormen Geschwindigkeitsvorteil bietet, z.B. Caching an einer häufig verwendeten Stelle, deren Inhalt sich aber selten, zumindest in der Scriptlaufzeit, nicht ändert. Weitergehende Optimierungen können dann nach Abschluss des Projekts stattfinden. Da kann man sowieso viel besser feststellen, welche Stellen besondere Nadelöre sind und diese dann refactoren.
Ich denke es kommt auf die Art der Optimierung an. Eine Mikro-Optimierung in PHP kann sich wirklich sparen, die Sprache ist schon so langsam (gegenüber anderen Sprachen), dass man mit der Mikrooptimierung kaum etwas gewinnt, aber die Geschwindigkeit reicht doch für 99% aller PHP-Installationen (Facebook mal aussen vorgelassen), also muss man da nichts ändern.
Interessanter wird die Diskussion jedoch, wenn man über DB-Optimierungen spricht, denn wenn ich die außen vorlasse und eine Datenbank ohne Sicht für die Zukunft designe kann es bei Projekten mit sehr schnellem Wachstum passieren, dass mir die Datenbank um die Ohren fliegt bevor ich „Mikrooptimierung“ sagen kann.
Wenn man dann noch bedenkt wieviel Zeit es kostet eine Anwendung zu ändern, um auf einem neuen Datenbankmodell zu arbeiten, da denke ich dann, ist hier eine „premature optimization“ gut angelegt, man sollte nur nicht den Überblick verlieren und wirklich jede Kleinigkeit optimieren (Mikrooptimierung).
ich hab das ganze mal ein bisschen ge-benchmark-t und bin bei jeweils einer million durchläufen beim post-increment auf 0,09 sekunden und beim pre-increment auf 0,08 sekunden gekommen. ist ein unterschied von 0,01 sekunden. und wie oft läuft im normalen gebrauch eine zählerschleife schon eine million mal durch?
@Daniel: Danke. Damit wäre wohl bewiesen, dass es keinen Sinn macht diese Optimierung durchzuführen.
Also der $i++ und ++$i setzte ich eigentlich gezielt ein(für den Verwendungszweck)
Im allgemeinen achte ich schon auf einen optimierte Code.. allerdings nicht im Sinne von Mikrooptimierung, zu dem gibt es noch ein Cachesysteme und auch noch obcode Caching – APC
Da viele MVC Frameworks ja, sowie so einen Overhead mit sich bringen, ist hier z.B.: eine Mikrooptimierung sinnlos.