• Vorträge

    Viele Vorträge, die auf Konferenzen gehalten werden, landen irgendwo im Internet. Wir haben sie für euch zusammengesucht.

    • Premature Optimization

    von Nils Langner am 4. November 2009

    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.

    Nils Langner Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    12 Kommentare »


    • Johann-Peter Hartmann
      am 4. November 2009 um 07:41 Uhr

      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


    • Nils Langner
      am 4. November 2009 um 08:21 Uhr

      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.


    • Timo
      am 4. November 2009 um 09:36 Uhr

      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


    • Don
      am 4. November 2009 um 12:01 Uhr

      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.


    • Nils Langner
      am 4. November 2009 um 12:06 Uhr

      @Don: Ich glaube Johann wollte was sehr ähnliches Sagen ;)


    • Johann-Peter Hartmann
      am 4. November 2009 um 13:15 Uhr

      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


    • Don
      am 4. November 2009 um 20:59 Uhr

      @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.
      ;-)


    • Nils Langner
      am 4. November 2009 um 21:16 Uhr

      @Don: Vielleicht hast du ja mal Lust einen Artikel über PHP 1.9 zu schreiben. So unter dem Motto: Es war einmal.


    • Ulf
      am 5. November 2009 um 00:24 Uhr

      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.


    • Don
      am 5. November 2009 um 02:42 Uhr

      @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!


    • Don’t assume! « Stephan Schmidt
      am 5. Januar 2010 um 20:42 Uhr

      [...] und Aufwand in eine Optimierung, die unter Umständen unnötig ist. Damit landen Sie nämlich bei Premature Optimization, und darüber hat Donald Knuth mal gesagt: Premature optimization is the root of all [...]


    • Die Guckloch Optimierung : Gjero Krsteski
      am 10. März 2010 um 18:03 Uhr

      [...] Informationen: PHP Optimieren Premature Optimization Optimiert Programmieren in PHP PHP-Benchmarks Der eAccelerator Caching für PHP [...]

    RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL

    Einen Kommentar hinterlassen

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.