Kategorien
Premature Optimization
Eigentlich wollte ich ja heute erzählen, wie man External Tools in Eclipse verwendet. Da ich die ganzen Daten aber bei der Arbeit habe und ich gerade eine Woche Urlaub habe, muss ich das leider mal wieder verschieben. Stattdessen geht es heute um „premature optimization“.
Der große Informatiker Donald Knuth hat mal den Satz geprägt „premature optimization is the root of all evil“ und ich finde den Satz eigentlich ganz passend. Mit dieser Art der Optimierung ist jene gemeint, die man anwendet, obwohl momentan noch keine Notwendigkeit zu sehen ist. Wir optimieren also, obwohl noch gar nicht klar ist, ob wie überhaupt an dieser Stelle optimieren müssen. Ich glaub ich habe gerade 10 mal Optimieren in einem Abschnitt geschrieben. Ich sollte eigentlich einen Preis dafür bekommen.
Warum ist das ganze aber keine gute Idee? Das Problem dabei ist, dass Optimierung fast immer Komplexität mit sich bringt. Vielleicht würde ein Caching System ja meine Methode schnell machen, also schnell einen Memcache installieren und die nötigen Pakete installieren. Klingt aufwändig und ist es auch. Was aber, wenn meine Methode gar kein Bottleneck ist? Dann habe ich gar ja gar nichts von der Optimierung, außer vielleicht den Award für das komplexeste Programm. Hätte ich meine Methode einfach so gelassen, schön simpel, aber vielleicht nicht ganz optimal, dann hätte ich immer noch ein einfaches System.
Ihr dürft moch aber nicht falsch verstehen, ich finde optimieren was wunderbares. Ich bin vielleicht sogar der größte Fan der Refaktorierung. Aber alles zu seiner Zeit. Sobald sich das Nadelör auftut, sollte man sich dem Code widmen, aber davor … neeeee. Wer sich jetzt fragt, wie man die Nadelöre am besten findet, dem sei die Lektüre zum Thema Profiling ans Herz gelegt. Es wird gemunkelt, dass im nächsten PHP Magazin ein Artikel darüber ist. Wenn der Artikel draussen ist, dann werde ich hier wohl auch noch was drüber schreiben.
Hi,
da muss ich dann doch noch mal meine 2c dazugeben.
Jede Optimierung das Ausnutzen von globalem Zustandswissen zur Reduzierung von doppelten oder einsparbaren Tätigkeiten im Execution Path.
Damit ist sie immer eine Reduktion der Separation of Concerns und Treiber von Abhängigkeiten zwischen Code-Komponenten und führt zu höheren globalen Kosten in Änderung und Wartung.
Aber: Eine Software, die ihre strategischen Requirements in Skalierbarkeit und Responsivität kennt nicht mit den architektonischen Schnittkanten versieht, die eine Optimierung in beiderlei Hinsicht ermöglicht, erzwingt Architekturumbau, und nicht Refactoring. Und das führt zu deutlich höheren Kosten und Folgekosten.
Konkretes Beispiel wäre etwa eine Skalierbarkeit der Schreiblast im Datenbankserver, die nur durch Zerlegung (dh. Sharding) der Daten anhand zB der User-Id geschehen kann. Wird das Domain Model im ORM ohne Berücksichtigung der Datenzerlegung entwickelt, steht hier bei der Optimierung ein kompletter Neuaufbau der Domainlogik an, und kein Refactoring.
Donald Knuth bezieht sich im Zitat direkt auf „small efficiencies“, also Optimierungen im Kleinen, und nicht auf Architektur.
Wer erst mit dem Erscheinen des Nadelöhrs an eine skalierbare Architektur denkt, obwohl das strategische Requirement bekannt ist, ist genau für Ausfälle a la Twitter etc verantwortlich.
(Das ist jetzt nur als Verfeinerung, nicht als Widerspruch gemeint 🙂 )
Liebe Grüße
Johann
Moin Johann, da hast du natürlich Recht. Eine Architektur umzubauen kann der Tod eines Projektes sein. Hier sollte man auf jeden Fall *vorher* ein wenig Gehrinschmalz reinstecken.
Leider geben die Tools um PHP auch nicht wirklich mächtige Werkzeuge mit, wenn es um Refaktoring geht. Wenn ich da an Java und Eclipse denke, da werde ich schon ab und zu wieder neidisch. Aber ich denke, dass wird die nächsten Jahre kommen und dann wird das einfacher.
Zuerst möchte ich Johann-Peter auf die Schulter klopfen, denn er hat recht. Genauso Nils, denn premature Optimization ist schlecht!
Bezüglich Refactoring:
Das wichtigste „Tool“ für Refactoring ist immer noch der UnitTest. Und zum Glück gibt es dafür bei PHP die entsprechenden Werkzeuge. Alle Anderen sind sehr hilfreich und beschleunigen, sind jedoch viel vermeidbarer als automatisierte Tests.
Cheers,
Timo
Refactoring Optimierung (i.S.v. Kluth)
Johanns Text habe ich zwar nicht ganz verstanden (liegt wohl auch an den komplexen Sätzen…[Absicht?]), mit Optimierung meinte der gute Herr Knuth aber m.W. ausschließlich den Bereich „Performance“ und nicht den Code, die Domain oder gar die Architektur selbst.
Ist vergleichbar mit einem Haus: ein Bild aufhängen oder eine Tür repairieren geht problemlos, den Grundriss oder die komplette Energieversorgung sollte man aber nicht sehr oft ändern.
@Don: Ich glaube Johann wollte was sehr ähnliches Sagen 😉
Hi Don,
Das mit der Vertretung von „Kluth“ hat ja mal noch Ausbaupotential.
Jepp, er bezieht sich nicht auf Architektur, das sage ich auch oben explizit:
„Donald Knuth bezieht sich im Zitat direkt auf “small efficiencies”, also Optimierungen im Kleinen, und nicht auf Architektur.“
Aber er meint schon Perfomance-Optimierungen im Code und im Design der Software.
Wikipedia sagt dazu: „Premature optimization“ is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code. This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing.
Aber mir gings eigentlich um einen anderen Punkt:
Mir sind in der PHP-Welt ein paar praktisch unoptimierbare Lösungen untergekommen.
In diesen Fällen ist eine Performance-Optimierung mit soviel Reengineering (dh. != Refactoring) verbunden, dass es sich uU gar nicht mehr lohnt.
Und das gemeine ist: das kann sogar dann passieren, wenn man ein super OO-Design hat, und Zerlegung und Architektur echt schön ist.
Deshalb noch mal die Ergänzung mit dem Blick auf ein optimierbares und skalierbares Design. Das widerspricht Knuth nicht, sondern sollte nur ein Missverständnis aufräumen.
Btw.: ich stehe jederzeit für einen Software-Architektur-Bitchfight zur Verfügung. Ich hab schon fast jeden Fehler gemacht 😉
Liebe Grüße
Johann
@Johann:
Gebe die in allen Punkten eine +1!
Nach 16 Jahren PHP (seit 1.9 beta !) habe ich auch schon jede Menge Mist gebaut und Bullshit gesehen.
Aber lange noch nicht alles, denn hätten wir alles schon gesehen, wären wir tot (geistig oder physisch).
„Bitchfight“ ist cool, bin ich gerne dabei.
😉
@Don: Vielleicht hast du ja mal Lust einen Artikel über PHP 1.9 zu schreiben. So unter dem Motto: Es war einmal.
Performance-Optimierung mit soviel Reengineering dass es sich gar nicht mehr lohnt- redet ihr von Magento? 😉
Im übrigen gebe ich Nils uneingeschränkt recht. Im Gegensatz zu Java Eclipse IDE sind die PHP IDE kleine Kinder. Natürlich sind auch Unit-Tests für das Refactoring unerlässlich, aber wenn ich bei Java mit Eclipse eine Methode umbenenne, dann brauche ich kein Unit Test.
@Nils
Du meinst so einen Retro-Artikel über PHP 1.9 und mSQL (ohne Y! – erinnert sich noch jemand daran?)
Waren zumindest spannend die ersten Jahre. Aber gut, daß es vorbei ist, hehe.
@Ulf
„…Magento“ – der war gut!