Softwareentwicklung in C++ - ASC

5. Funktionen 101
feilscht (=lineare Ersparnis), obwohl ein Algorithmus mit Komplexität
O(n 2 ) (=quadratischer Verlust) oder schlimmer im Einsatz ist.
Um das Gesagte zu untermauern, möchte ich hier eine kleine Geschichte
erzählen, die sich im Jahr 1990 ereignet hat: Es wurde ein Paket zur Berechnung
einer speziellen Regression auf einer für damals sehr leistungsfähigen
Unix-Workstation entwickelt. Leider war ein sehr naiver Entwickler
am Werk, der keine Rücksicht auf die Beschaffenheit der Daten nahm
und wahnwitzigste Matrix-Operationen, mit einer Laufzeitkomplexität von
O(n 2 ) bis O(n 3 ), je nach Art der Berechnung, implementierte.
Ergebnis: Ein Programmlauf dauerte im Durchschnitt zwei Tage. Der
verzweifelte Entwickler investierte viel Zeit in sehr naive Laufzeitoptimierung
(hier ein paar Statements, dort ein paar...), aber der Erfolg war nur
minimal. Der beste Wert wurde mit 1 1/2 Tagen Laufzeit erreicht.
Nachdem der mittlerweile völlig entnervte Entwickler aufgab, wurde das
Programm auf seine Komplexität untersucht und einem entsprechenden
kompletten Redesign unterzogen. Besonderes Augenmerk wurde hierbei
auf interne Datenstrukturen gelegt. Der Zeitaufwand vom Beginn des
Redesigns bis zur fertigen Implementation betrug weniger als die Hälfte
der zuvor zur sinnlosen Optimierung investierten Zeit. Der Erfolg war
aber durchschlagend: Die Komplexität aller Berechnungen lag nunmehr
bei O(n). Damit wurde die Laufzeit des Programms, mit denselben Daten
wie zuvor, auf weniger als eine Minute reduziert!
Als kleines Detail am Rande wäre hier noch zu erwähnen, dass das sinnvoll
optimierte Programm sauber und gut lesbar war. Ganz im Gegensatz zu
dem Meisterwerk, das durch den verzweifelten ersten Optimierungsversuch
entstand, denn dieses war durch das Herausquetschen der letzten kleinen
Instruktionen einfach gar nicht mehr lesbar.
• Damit Komplexitätsverbesserungen garantiert den gewünschten Effekt
bringen, sollte man auf jeden Fall auch auf die worst-Case Komplexität
eines Algorithmus losgehen, nicht nur auf den Durchschnitt (außer, man
kann den worst-Case garantiert ausschalten). Das bekannteste Beispiel
eines Algorithmus mit O(log(n)) average-Komplexität, die allerdings zu
O(n 2 ) im worst-Case entarten kann, ist Quicksort. Wenn man diesem die
“falschen” Daten füttert ist es ganz und gar nicht mehr so quick :-).
• Performancetests sollten immer auch auf viel zu gering ausgestatteten Systemen
mit gleichzeitig viel zu großer Belastung stattfinden. Auf diese Art
lassen sich leichter unangenehme Effekte finden (auch sehr geeignet für den
Test auf subjektive Performance!).
• Während der Phase der Optimierungen muss man immer darauf achten,
nur eine Sache auf einmal zu optimieren und dann einen Vergleichstest
durchzuführen. Der Grund dafür ist einfach zu erkennen: Wenn man in
einem Programm an mehreren Baustellen gleichzeitig arbeitet, lässt sich
nicht mehr sagen, von welcher der Maßnahmen nun welcher Effekt ausgeht.