Premature Optimization - noch einmal
Kurz nachdem ich meinen Blog-Eintrag Performance und die Ausrede der verfrühten Optimierung hier gepostet habe, erschien unter dem Titel "The Second Law of Optimization" ein lesenswerter Beitrag von Ashod Nakashian zum gleichen Thema.
Im Wesentlichen sagt auch Ashod, dass man wissen muss, wo und wann es sich lohnt, von vornherein zu optimieren und wo man dies besser unterlässt:
As we’ve already iterated, designing and writing efficient code doesn’t necessarily mean premature optimization. It just means we’re responsible and we are balancing the cost by investing a little early and avoiding a high cost in the future.
Ashod Nakashian: The Second Law of Optimization, Juni 2011
Ashods Schwerpunkt liegt weniger auf den Auswirkungen der Architektur (obwohl er diese auch erwähnt), als vielmehr auf der vernünftigen Entscheidung für geeignete Datenstrukturen und/oder Algorithmen für ein Problem. Ein Thema, das ich in meinem Posting nicht behandelt habe.
Ich empfehle, den ganzen Beitrag (oder doch zumindest Ashods eigene Zusammenfassung für Eilige) zu lesen, will aber zumindest ein Beispiel wiedergeben:
It’s not premature optimization to use dictionary/map instead of a list or the most common container in your language of choice. Not when we have to read items most of the time. It’s not premature optimization if we use an O(n) algorithm instead of the O(n2) that isn’t much more complicated than what we’ll use (if not an O(log2 n) algorithm). It’s not premature optimization if we refactor a function so it wouldn’t handle multiple unrelated cases. Similarly, moving invariant data outside a loop isn’t premature optimization. Nor is caching very complex calculation results that we don’t need to redo.
Ashod Nakashian: The Second Law of Optimization, Juni 2011
Gute Beispiele für sinnvolle Optimierungen, deren späterer Einbau mit dem dazugehörigen Umbau des restlichen Codes deutlich aufwendiger wäre, als dies gleich zu bedenken. Das ist ein wichtiger Aspekt, der in meinem Posting eindeutig zu kurz kam. Von unterschiedlichen Ausgangspunkten kommend, sind wir aber beide zu dem gleichen Schluss gekommen: Man muss wissen, wann es sich lohnt, rechtzeitig nachzudenken und wo man dies übertriebenen Ehrgeiz bedeutet:
There are no excuses to writing inefficient code if the alternative is available at a small or no cost. There is no excuse to not thinking the algorithm ahead of typing. No excuse to leaving old experimental bits and pieces because we might need them later, or that we’ll cleanup later when we optimize. The cost of poor design, badly performing code is very high. It’s the least maintainable code and can have a very high cost to improve.
Ashod Nakashian: The Second Law of Optimization, Juni 2011
Also es gilt weiterhin:
Know when to play dumb! :-)
Gepostet am 29.06.2011 um 10:55 | Kommentare[0]