Es gibt Bereiche, wo die generelle Optimierung mit Recht als sinnvoll angesehen wird:

• CompilerProgrammierung
• BetriebssystemProgrammierung?
• SpieleProgrammierung
• EmbeddedSoftware?
• ...

• ApplikationsEntwicklung? allgemein (mit der Ausnahme bestimmter zeitkritische Operationen)
• KommerzielleProgrammierung? (mit der Ausnahme bestimmter zeitkritische Operationen)
• ...

Gibt es Wege, Optimierung sinnvoll durchzuführen ?

Mein Weg sieht so aus:

• Im ersten Wurf entwickle ich Software möglichst schnell und unoptimiert. Ich achte dabei auf:
• Nicht durch verfrühte Optimierung Architekturschwächen einzubauen (ich hab bis jetzt immer bereut, nicht so gehandelt zu haben ... )
• Ich achte auf einige grundlegende PerformanceArchitekturPatterns? (schlanke Schnittstellen, Objekt Reusing ermöglichen, Kapselung von Performance-bedürftigen Algorithmen und zugehörigen Strukturen)
• Explizit: Für den ersten Wurf keine Daten / Berechnungsergebnisse cachen.
• Beim fertigen Produkt dann im Falle von fehlender Performance, durch Profiling ermitteln, wo optimiert werden muß !
• Für diese Fälle Performance-Test formulieren
• Diese Tests durch Optimierung erfüllen.

Etwas was mir in der Hinsicht bei meinem Computergame Probleme macht: Ich entwickle auf einem 1.5GHz Prozessor mit einer schwachen 3D-Karte (Matrox G400). Abgabe PC ist ein P-III 500MHz (deutlich schwächer als mein AMD) mit einer GeForce3? (deutlich schneller als meine G400). Dadurch kam es zu dem faszinierenden Paradoxon, daß das Spiel dort deutlich schlechter (niedrige fps) als auf meinem Rechner, da die CPU-Berechnungen pro Bild viel zu lange brauchten. Wenn ich mich jedoch stärker auf die Graphikkarte stütze - was mit der GeForce3? kein Problem ist - kann ich es zuhause nicht mehr so gut testen. -- DavidSchmitt

Ich mit dem Thema Optimierung folgende Erfahrungen gemacht:

• Es war nötig an Stellen zu optimieren, die mir von vornherein niemals in den Sinn gekommen wären.
• Ich habe viele Schieflage Projekte kennengelernt, bei denen von Anfang an 'Performance eingebaut wurde'. Dabei geht der Blick für die systemübergreifende Performance Anforderungen verloren und wird durch viele Feintunings ersetzt. Im Endeffekt wird die Applikation dadurch wesentlich langsamer und natürlich unwartbar.
• Wenn ich mich nicht an die Zügel nehme, baue auch ich die o.g. lokalen 'Perfromanceverbesserer' ein ...
• Manchmal muss zur Performancesteigerung auch refactored werden. Durch umfangreiche Test wird ein solches Refactoring schneller und Randbedingungen leichter abschätzbar.
• Nicht jeder als performant eingestufte komplexe Algorithmus hat sich auch als performant herausgestellt (Kapselung der Algorithmen / StrategyPattern)
• Datencaching ist sehr komplex und die Synchronisation ist fehleranfällig. Soll Caching eingesetzt werden, muß das gut begründet sein.

Warum soll es keine Wege geben, Optimierung sinnvoll durchzuführen? Wichtig ist es, das Optimieren nicht als eine Form des Programmierens zu sehen, die im Prinzip jeder machen kann, dem die Aufgabe gestellt ist. Optimieren ist etwas, das einer gewissen Fertigkeit und einer systemnahen, emprischen Denkweise bedarf, die manchen Leuten mehr liegt und manchen weniger. Man kann das üben, in dem man hin und wieder ernsthaft versucht, das letzte aus einem Code herauszuholen und Bücher wie ProgrammingPearls liest. Optimieren ist eher wie Rätselfragen lösen, als wie Programmieren. Wenn man einmal so 6-12 Arbeitsmonate in Optimierungen hineingesteckt hat, bekommt man einen Instinkt dafür. Man kann dann ohne jeden Aufwand Systeme so anlegen, dass sie die gröbsten Performanceprobleme vermeiden und einer späteren Optimierung zugänglich sind. -- HelmutLeitner

Soll ich dann fragen: Was ist der Weg zur sinnvollen Optimierung ?

Ich bin der Meinung, daß Optimierung eher ein eigener, expliziter Arbeitsschritt als eine ständig nebenher lauffende Aufgabe ist. -- mj

Das Problem hat eigentlich zwei verschiedene Seiten: WallClockTime? und BenutzerEmpfinden?.

• Eine Implementation, die tatsächliche Ausführungszeit durch BubbleSort? vergeudet statt zB QuickSort zu verwenden ist IMO fehlerhaft. Bei größeren Datenmengen, kommt es hier unweigerlich zu unnötigen Performanceeinbrüchen. Zugegeben, einige dieser "Bugs" sind schwerer zu finden als double-free Fehler, aber es gibt Profiler (kennt da wer was gescheites für das VisualStudio??) und Hausverstand.
• Auf der Seite der Benutzerpsychologie ist es oft genug eine hinreichend genaue (feinauflösende/korrekte) Fortschrittsanzeige einzubauen um den Benutzer zufriedenzustellen.

"Es gibt Bereiche, wo die generelle Optimierung mit Recht als sinnvoll angesehen wird"

Tatsächlich? Macht es wirklich einen Unterschied, ob ein Button nach 1 oder 20 Millisekunden reagiert? [Das menschliche Auge reagiert schon auf geringste Verzögerungen. Wenn unter Windows jeder Button 20ms brauchen würde, bevor sich was tut würden wir wahrscheinlich alle auszucken] Oder sollte man vielleicht auch hier genauso gezielt die zeitkritischen Operationen behandeln? Oder anders herum gefragt: Wo liegt der Gewinn darin, eine Operation zu optimieren, die nicht zeitkritisch ist?

Wo liegt der Gewinn für den Enduser, daß neue Versionen einer Software eine neue PC-Generation brauchen?

Bei oberen Bereichen ist eben die Mehrheit des Codes zeitkritisch und die Performance ist ein ständiges Entwicklungsziel. Also gibt es bei den Personen und den Firmen eine hohe Wertschätzung für optimierendes Arbeiten, das ist quasi Teil der 'Entwicklungskultur'. Das gibt genauso viel Sinn, wie die gegenteilige Einstellung in den unteren Bereichen. -- hl

• Optimierung ist teuer. Nicht nur, dass es Zeit kostet, Code zu optimieren, in den meisten Fällen ist (performance-)optimierter Code auch aufwendiger zu warten. Da Kosten und Gewinn von Performance-Optimierungen kaum als proportional angesehen werden können, muss man sich sehr genau überlegen, welche Optimierungen wirtschaftlich sind, und welche nicht.
• Der Gewinn durch Performance-Optimierung ist alles andere als trivial zu ermitteln. Bereits die Ermittlung der Zeit, die durch Optimierung für die Ausführung einer Operation gespart werden kann, ist im Zeitalter moderner Compiler und Laufzeitumgebungen (z.B. Prozessoren) mit eigenen komplexen Optimierungsalgorithmen nicht ganz einfach. Ebenso wichtig für eine Beurteilung sind Häufigkeit und Kontext der Ausführung der Operation. Diese Abhängigkeiten sind häufig kompliziert genug, dass nur eine Analyse am laufenden Programm relevante Rückschlüsse zulässt. Solch eine Analyse ist natürlich um so aussagekräftiger, um so später im Produktentwicklungszyklus sie durchgeführt wird.

Das ist eben eine religiöse Frage.

Ich denke nicht, dass jede Diskussion die nicht innerhalb kürzester Zeit zu einem Konsens führt, in den Bereich der ReligionsKriege fällt. Ich weiß nicht, warum Du das Gefühl hast, dem wäre hier so; ich hoffe jedenfalls, aus dieser Diskussion noch einiges lernen zu können.

SoftwareEntwicklung findet statt, weil es einen Auftraggeber gibt, der die Entwicklung finanziert (das kann natürlich auch der Entwickler eines Shareware-Paketes selber sein, der seine Zeit einbringt). Es ist Sache des Aufttraggebers festzulegen, was entwickelt werden soll und mit welchen (Optimierungs-)Zielen die Entwicklung erfolgen soll. Grundsätzlich sehe ich keinen Unterschied, ob jemand "Time to Market", "Performance", "Entwicklungskosten", "Wartbarkeit" oder "Wiederverwendbarkeit" optimieren will. Der SoftwareEntwickler sollte meiner Meinung nach kein Missionar sein, sondern die Intentionen des Auftraggebers umsetzen. -- hl

Selbstverständlich ist es Aufgabe des Auftraggebers, die Prioritäten der Entwicklung festzulegen. Und natürlich gibt es Gründe für eine 'generelle Optimierung' (z.B. weil es Spaß macht, weil man etwas bei lernt etc.). Ich denke nur nicht, dass es ökonomische Gründe für eine solche Entscheidung geben kann.

Der übliche Auftraggeber will ja nicht 'Performance um jeden Preis' (denn sonst würden wir wohl alle grundsätzlich in Assembler programmmieren); er möchte eine Form von Kompromiss zwischen den von Dir genannten Eigenschaften (und, nicht zu vergessen, "Verwendbarkeit"). Unsere Aufgabe als SoftwareEntwickler ist es, die beste technische Möglichkeit zu finden, den Performance-Ansprüchen des Auftraggebers gerecht zu werden. Ich denke nicht, dass 'generelles Optimieren' diese Ansprüche erfüllt, lasse mich aber gerne vom Gegenteil überzeugen.

Es macht allerdings durchaus Sinn, in einigen Bereichen selbst in der Anwendungsentwicklung Optimierungen durchzuführen. Dies wird der Kunde, wie im obigen Fall erwähnt, zwar nicht bezahlen wollen, allerdings wird er es auch nicht akzeptieren unzulässig 'langsame' Programme abzunehmen. Als Beispiel sei hier der Button erwähnt. Wenn dieser sofort auf die Benutzereingabe reagiert und ein Programm erst danach 'zu arbeiten' anfängt, ist dies ein wesentlich besseres GUI. Insofern trägt der Button der innerhalb einer Millisekunde reagiert zur Akzeptanz eines Produktes bei. Dies ist auch der Grund, weshalb der Mauszeiger bei den neueren BS die höchste Prozessorzeit bekommt. -- cc

Moment mal... wieso soll man ausgerechnet an einem Compiler blindwütig optimieren? Ein optimierender Compiler ist etwas anderes als ein optimierter Compiler. Ich möchte erstens einen korrekten Compiler, zweitens einen, der für mich optimiert und erst drittens einen, der selbst optimiert ist (auf Geschwindigkeit und Platzbedarf vermute ich mal). Gerade ein Compiler ist überhaupt kein zeitkritisches Stück Software. (Wobei ich anerkenne, das Teile(!) von Betriebssystemen und Actionspielen durchaus optimierungswürdig sind. Wie üblich nach dem Profilieren.)

WardsWiki:LazyOptimization