Software Optimierung
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Mit SoftwareOptimierung ist die Verbesserung des Platz- und/oder Zeitbedarfs eines Programmes gemeint. Man kann auch viele andere Eigenschaften von Software, wie etwa die Lesbarkeit oder das Design optimieren, aber das ist hier nicht gemeint.
Die erste und wichtigste Regel der SoftwareOptimierung lautet:
Wenn diese Regel aus irgendeinem Grund nicht anwendbar ist, kommen folgende Regeln zum Zug:
- 2. Optimiere später
- 3. Optimiere nur, wenn es einen nachgewiesenen Optimierungsbedarf gibt
- 4. Optimiere frühestens dann, wenn ein funktionell vollständiges Gesamtprogramm vorliegt
- 5. Optimiere grundsätzlich nur vorher identifizierte Engpass-Bereiche.
- 6. Optimiere nie ohne ein exaktes Meßsystem und Erfolgskontrolle jedes einzelnen Optimierungsschrittes.
Diese Regeln wurden von Experten für "Normalprogrammierer" aufgestellt, die fast immer mehr Schaden anrichten als Nutzen bringen, wenn sie optimieren. Denn Optimierung kostet viel Zeit und Geld. Meist schlägt sich Optimierung nicht in einem merkbaren Kundennutzen nieder, sodass der Aufwand an der falschen Stelle investiert wurde. (Siehe auch die Diskussion dazu: SoftwareOptimierungDiskussion)
WENN man unbedingt optimieren möchte (oder muss), dann gibt es dafür spezifische SoftwareOptimierungsTechniken.
Im Folgende sollen jedoch einige Beispiele eingefügt werden, die dokumentieren, wie leicht man an der falschen Stelle oder mit ungewollten Effekten optimieren kann, und warum es besser ist, nicht zu optimieren.
- Assume nothing. I cannot emphasize this strongly enough - when you care about performance, do your best to improve the code and then measure the improvement. If you don't measure performance, you're just guessing, and if you're guessing, you're not likely to write top-notch code.
- Michael Abrash, ZenOfCodeOptimization
Erstes Beispiel:
- Wir hatten eine kleine SpikeSolution programmiert, eine Web-Oberfläche für (nicht allzu) verschiedene Formulare per XML/XSL mit Hilfe von Xalan in Java zu realisieren. Der Aufbau einer (nicht sehr komplexen) Seite dauerte dabei um die zwei Sekunden - das war natürlich inakzeptabel. Daher beschlossen wir, eine Optimierungsmöglichkeit von Xalan zu nutzen, nämlich vorkompilierte XSL-Dateien.
- Um zu testen, wieviel Geschwindigkeitsgewinn dieses Vorgehen bringen würde, schrieben wir einen kleinen Benchmark, der zehn Seiten von XML nach HTML transformierte. Wie sich dabei herausstellte, optimierte die HotSpotEngine? auf eine Art und Weise, dass die zweite Seite noch anderthalb, die vierte eine Sekunde und die zehnte zwei Hundertstelsekunden benötigte. Kaum erwähnenswert, dass wir nicht weiter über eine Optimierung nachdachten.
- Zwei Tage später entschied sich der Kunde für eine Oberfläche mit Swing-Applets...
Zweites Beispiel:
- Programmierung von Taxi-Schach (einer vereinfachten Schach-Variante) in Prolog ( http://wwwwbs.cs.tu-berlin.de/fachgebiete/wbs/ws0001/spiele/).
- Kurz vor dem Abgabetermin wollte ich noch ein wenig die Performance unseres Programms optimieren; für die Analyse der Stellung, die ich zum Testen wählte, brauchte der Computer anfangs ca. 20 Sekunden. Nach kurzer Code-Inspektion fiel mir auf, dass das Prädikat zum Testen auf eine Gewinnstellung jeweils zweimal für die gleiche Stellung aufgerufen wurde. Dieses Prädikat musste unter anderem Herausfinden, ob sich der Gegner noch bewegen kann und tat dies, indem es sich einfach eine Liste aller möglichen Züge geben ließ und prüfte, ob diese leer war. Ein nicht zu unterschätzender Overhead (dachte ich), also machte ich mich daran, den Code so umzustricken, dass die Abfrage nur noch einmal nötig war. Performance-Gewinn nach zehn Minuten Arbeit: nicht spürbar!
- Also machte ich mich doch daran, den Profiler auszuprobieren. Dabei stellte sich heraus, dass ein nicht unwesentlicher Teil der Rechenzeit in einem einzeiligen Prädikat verbracht wurde, das prüft, ob sich ein gegebener Feldindex noch auf dem Brett befindet. Das Prädikat verglich den gegebenen Index einfach mit der Liste der Legalen Indizes. Skeptisch, ob das etwas bringen würde, machte ich mich dennoch daran, diese Zeile durch drei etwas kompliziertere Berechnungen zu ersetzen. Immer noch skeptisch startete ich den Test und erhielt das Ergebnis ... nach 15 Sekunden! Zu meiner absoluten Überraschung hatte ich mit dieser winzigen Änderung einen Performance-Gewinn von 25% erreicht...
-- IljaPreuß
Beispiel 3: (DavidSchmitt)
Vorher:
| template<class T> class vector3D
{
public:
vector3D() : data(new T[3]) {};
/*...*/
private:
T* data;
} |
|
|
Nachher:
| template<class T> class vector3D
{
public:
vector3D(){};
/*...*/
private:
T data[3];
} |
|
|
Operationen, die große 3D-Datenmengen laden (und entsprechend viele Vertices erzeugen) brauchen jetzt nur mehr halb so lange. So trivial wie diese Änderung ist, frage ich mich: ist das Optimierung oder war das Original einfach nur besch*** programmiert?
Links:
SoftwareOptimierungDiskussion SoftwareOptimierungsTechniken
KategorieOptimierung
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 15. Juli 2003 10:49 (diff))