Gute Gründe nicht zu optimieren

Es gibt sehr gute und triftige Gründe nicht zu optimieren. Meist steht der Punkt Optimierung der Anwendung erst dann an, wenn das Programm fehlerfrei lauffähig ist. Bei kleinen Anwendungen ist dies auch ein probates Mittel, da die Umsetzung hier im Vordergrund steht. Dies führt jedoch zu einigen Gründen, warum Sie nicht optimieren sollten:

  1. Bei der Optimierung Ihrer Anwendung kann viel Zeit und Geld investiert werden, ohne dass es zu spürbaren Veränderungen kommt.
  2. Optimierungen können zu schlechter lesbaren und wartbaren Quelltext führen.
  3. Optimierungen können zu (neuen) Fehlern in Ihrer Anwendung führen.
  4. Optimierungen sind meist abhängig von Compilern, Ausführungsplattform und anderen Teilen der Anwendungsumgebung.
  5. Der / Jeder Objektorientierungsgedanke kann bei der Optimierung verloren gehen.

Keiner dieser Punkte muss Ihre Anwendung betreffen; Sie sollten jedoch vorher abwägen, ob es sinnvoll ist eine Optimierung durchzuführen, wenn die Anwendung in einer Art und Weise lauffähig ist die keinerlei (Performance)–Problem hervorruft.

Gründe zu optimieren

Wenn Sie Ihre Anwendung optimieren müssen dann liegt es meist an diesen Punkten:

  1. Ihre Anwendung benötigt zu viele Ressourcen:
    1. Speicher
    2. Prozessorkapazität
    3. Bandbreite
  2. Ihre Anwendung findet aufgrund dieses Problems keine Akzeptanz.
  3. Ihre Anwendung erfüllt nicht die Anforderungen des Auftraggebers.
  4. Ihre Anwendung ist ohne Optimierung nicht sinnvoll lauffähig.

Bei jedem dieser Punkte ist zuerst einmal Analyse zu betreiben, wo der eigentliche Schwachpunkt liegt und wie dieser aus dem Weg geräumt werden kann. In den verschiedenen hier dargestellten Teilen werden Ansätze gezeigt, wo eine Optimierung sinnvoll sein kann.

Wann sollten Sie optimieren?

Im Abschnitt „Gründe zu optimieren“ sind bereits wesentliche Punkte für das Optimieren aufgezählt worden. Wenn wir diesen Abschnitt mit dem Abschnitt „Gute Gründe nicht zu optimieren“ vergleichen lassen sich schon einige Grundregeln für den Zeitpunkt einer Optimierung festlegen.

Performanceoptimierungen sollten nur dann durchgeführt werden, wenn es zu einem Ressourcenengpass, mangelnder Akzeptanz (durch Benutzer oder Auftraggeber) oder zu keinem sinnvoll lauffähigen Produkt kommt.

Ein weiteres Ziel sollte es sein Optimierungsmöglichkeiten außerhalb der Anwendungserstellung zu nutzen. Um diese jedoch wirksam testen zu können, ist zumindest ein funktionierender Prototyp Voraussetzung. Auf jeden Fall sollten nötige Performanceoptimierungen vor der eigentlichen Anwendungsauslieferung erfolgen.

Die Performanceoptimierung sollte schließlich zuerst auf das Design zielen bevor die Implementierung in das Visier rückt. Dies hat einige weitere Vorteile: Ein gutes und performantes Design erhöht die Wartbarkeit einer Anwendung erheblich. Bei Performancegewinnen durch Änderung des Design entsteht kein „Trashcode“. Natürlich ist hier insbesondere darauf zu achten, dass die Designoptimierung nach Möglichkeit nicht zu einem schlechten Design führen sollte. Der Einbau eines Cache oder Objektpools in das Design ist sicherlich positiv zu bewerten, während der direkte Zugriff auf Variablen ebenso wie die Auflösung der Trennung von Anwendung und Oberfläche (Stichwort MVC) eher in den Teil schlechtes Design fällt[1].

Bleibt zum Schluss nur noch die Feststellung, dass in der Analysephase keine Performanceüberlegungen durchgeführt werden. Hier geht es um die fachlichen Anforderungen die Ihre Anwendung bewältigen muss, nicht deren Umsetzung [2].

Wo sollten Sie optimieren?

Es gibt mehrere wesentliche Ansatzpunkte, um Ihre Anwendung performanter zu gestalten. Sie können Optimierungen in der Anwendungs- / Systemumgebung vornehmen, im Design und in der Implementation. Jeder dieser Punkte hat seine Vor- und Nachteile sowie seine Daseinsberechtigung. Grob kann man diese Teile wie folgt umreißen:

Optimieren der Anwendungs- bzw. Systemumgebung (Laufzeitumgebung) bedeutet Verbesserungen (meist) ohne direkten Eingriff in die Anwendung. Der Eingriff kann z.B. beim Wechsel der Datenbank nötig sein. Optimierungen werden dabei speziell auf die jeweilige Umgebung abgestimmt und sind nur selten auf andere Systeme übertragbar. Beispiele wären der Einsatz einer anderen JRE oder Datenbank oder auch das Erhöhen des Umgebungsspeichers für die Java Virtuelle Maschine.

Optimieren des Designs bedeutet fast immer einen grundsätzlichen Umbau der Anwendungsstruktur. Dies zieht somit auch Implementierungsarbeiten nach sich. Der Vorteil ist jedoch, das der Quelltext zu einem hohen Anteil eins zu eins in die neue Struktur übernommen werden kann (Copy & Paste) oder nur geringe Anpassungen nötig sind. So kann der Einbau eines Cache innerhalb einer Klasse auch ganz ohne Änderung der Abhängigen Strukturen erfolgen. Hier bietet sich auch der Einsatz von bestimmten Entwurfsmustern an.

Die Optimierung in der Implementation (hier ist nicht die Folgearbeit nach Designoptimierung gemeint) soll schließlich schnelleren Quelltext erzeugen, ohne dass dieser nicht mehr wartbar wird. Dies bedeutet im Idealfall den Einsatz eines besseren Algorithmus.

Obwohl ich hier bewusst von einigen Optimierungsmöglichkeiten wie direkten Zugriff auf Objektvariablen abrate, werden auch diese Möglichkeiten im Laufe dieses Dokumentes zur Vollständigkeit näher besprochen.

Was sollten Sie optimieren?

Wo und Was greift natürlich sehr ineinander. Zuerst also noch einmal „Wo sollten Sie optimieren?“ – in der Anwendungsumgebung, in dem Design und in der Implementierung. Während Sie sich bei der Anwendungsumgebung und im Design keinerlei Grenzen zu stecken brauchen, ist bei der Implementierung, also dem Quelltext, etwas mehr Vordenken gefordert.

Die 80 / 20 Regel

Eine Feststellung die sich in den Jahren seit den ersten Programmzeilen herauskristallisiert hat, ist, dass 80% der eigentlichen Aufgabe einer Anwendung in etwa 20% des Quelltextes erledigt wird. Typisches Beispiel dafür ist eine Schleife. Schleifen, insbesondere häufig durchlaufende, enthalten in sich Quelltext der während der Anwendung wesentlich häufiger ausgeführt wird. Es ist daher sinnvoller diesen Teil zu optimieren, als den umliegenden Quelltext. Das Problem welches sich dann meist stellt, wie findet man diese 20% Quelltext. Hier hilft der Einsatz von Profilern. Profiler sind Anwendungen, welche in der Lage sind die Performanceeigenschaften andere Anwendungen zu messen.

Wann sind Sie fertig mit der Optimierung?

Ein Ende der Optimierungsarbeiten ist entweder nie oder genau dann erreicht, wenn Ihre Gründe zu optimieren nicht mehr bestehen. Selbst dann kann jedoch wieder ein Optimierungsbedarf neu entstehen. Je nach entwickelter Anwendung gibt es jedoch noch Unterschiede zu beachten.

Interaktive Software

Interaktive Software, also Anwendung mit direkten Benutzereingaben sollten eine Reaktionszeit von etwa 0,2 Sekunden erreichen. Für den Anwender erfolgt somit eine sofortige Reaktion unserer Anwendung. Sofern mehr als ein Sinnesorgan direkt angesprochen wird z.B. bei Akkustischen Wiedergaben sollten Sie eine Reaktionszeit von 0,02 Sekunden erreichen (oder auch Hand-Auge-Koordnationsbasierte Anwendungen).

Animationen müssen nie schneller sein, als die Bildwiederholfrequenz des darstellenden Display. Ähnliches gilt für Bilder und Soundeffekt - benötigen Sie z.B. wirklich eine verlustelose Komprimierung oder reicht auch MP3?

 


[1]  Im Vorgriff sei nur soviel gesagt, dass es sich bei jedem dieser Punkte um Möglichkeiten handelt dir Performance der Anwendung zu erhöhen.
[2] Hier wird auch keine Annahme darüber getroffen, welche Implementierungssprache gewählt wird. Es sollte daher ggf. auch Mehrfachvererbung eingesetzt werden. Sofern man dies strikt auslegt gibt es auch keine Variablentypen wie boolean oder String sondern nur Typen ähnlich Wahrheitswert, Zeichenkette der Länge 12 u.ä.