Die RCP-Anwendung, an der ich auf der Arbeit programmiere, reagiert bei größeren Dateien mit einer gewissen Behäbigkeit auf Tastatureingaben. Und wenn der Rechner langsam genug und die Dateien groß genug sind, verlieren auch weniger ungeduldige Leute als ich ihre Nerven. Es war also nach sieben Monaten mal nötig, sich intensiver mit der Performance unserer Applikation zu beschäftigen. Warum wir das nicht schon viel früher gemacht haben?

“The First Rule of Program Optimization: Don’t do it. The Second Rule of Program Optimization (for experts only!): Don’t do it yet.” – Michael A. Jackson (Nein, nicht der Thriller-MJ. RIP :-()

oder auch

„We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.“ (Donald Knuth)

Aber nun war es doch mal nötig, sich damit zu beschäftigen. Einfach drauflos zu optimieren hat natürlich keinen Sinn, man muss zuerst einmal wissen, welche Abschnitte wirklich Zeit kosten. Dabei können einem Profiler-Tools helfen. Wir haben TPTP eingesetzt, um einen Eindruck davon zu bekommen, in welchen Methoden unser Programm einen Großteil seiner Zeit verbringt.

Standardmäßig ignoriert TPTP dabei unter anderem alle Pakete, die mit „org“ beginnen, was in unserem Fall nicht so erwünscht war. Eine zusätzliche Regel, die Pakete unter „org.eclipse.jst.pagedesigner“ explizit miteinzubeziehen, hat dieses Problem für uns gelöst. Da der Overhead für diese Analysen zur Laufzeit enorm ist, ist es allerdings schon sinnvoll, nur innerhalb der Klassen zu testen, an die man wirklich heran kommt. So konnten wir herausfinden, dass der Großteil der Laufzeit beim Einfügen von Zeichen für Code draufgeht, der sich um das Synchronisieren der grafischen Darstellung und die Validierung der Eingabeposition kümmert. Bei der weiteren Entwicklung hat es sich dann als nützlich erwiesen, mit folgendem Code zu prüfen, welche Methoden innerhalb einer offenbar aufwändigen Methode den Großteil der Arbeitszeit in Anspruch nehmen. Denn nur an diesen Stellen möchte man überhaupt etwas ändern. Schließlich bringt jede Änderung das Risiko mit sich, irgendetwas kaputt zu machen;-)


long time = System.currentTimeMillis();
doSomething();
System.out.println("doSomething: "+(time-System.currentTimeMillis()));
time = System.currentTimeMillis();
doSomethingElse();
System.out.println("doSomethingElse: "+(time-System.currentTimeMillis()));

Ein weiteres nettes Tool zum profilen von Java-Applikationen ist visualVM, dass von Sun mit dem JDK mitgeliefert wird. Damit kann man bereits laufende Java-Anwendungen unter die Lupe nehmen. Leider lief es in unserem speziellen Fall nicht schnell genug und lieferte keine relevanten Ergebnisse, aber für viele einfacher aufgebaute Java-Anwendungen ist das eine gute Option.

Mit Hilfe der Werkzeuge und einigen Aussparung von vermeintlich überflüssigem Code konnten wir die Eingabegeschwindigkeit vielfach erhöhen. Bevor wir diese Änderungen ausliefern, werden wir aber lieber testen, ob wir wirklich nichts kaputt gemacht haben…