Ein paar Bemerkungen zu Swing, NetBeans Platform und Performance Aljoscha Rittner Sepix GmbH, NetBeans Dreamteam Member

Agenda ● Problemstellung ● Java ist langsam ● Swing ist langsam ● Threads entwirrt ● Lösungen ● Profiler ● Threading sinnvoll einsetzen ● Tweaking the VM

Agenda ● Problemstellung ● Java ist langsam ● Swing ist langsam ● Threads entwirrt ● Lösungen ● Profiler ● Threading sinnvoll einsetzen ● Tweaking the VM

Java ist langsam? Java gilt als Interpretersprache und soll langsam sein Garbage Collector stört die Laufzeitumgebung Objekte in Java sind zu schwerlastig it depends, it depends, it depends

Agenda ● Problemstellung ● Java ist langsam ● Swing ist langsam ● Threads entwirrt ● Lösungen ● Profiler ● Threading sinnvoll einsetzen ● Tweaking the VM

Swing ist langsam? ● Menüs, Buttons, Listen und Tabellen reagieren schwerfällig ● Ständig hängt die Anwendung und man kann nicht weiterarbeiten Old Java 5 Problem

Agenda ● Problemstellung ● Java ist langsam ● Swing ist langsam ● Threads entwirrt ● Lösungen ● Profiler ● Threading sinnvoll einsetzen ● Tweaking the VM

Threads entwirrt So was modernes wie Java kann doch mehrere Dinge gleichzeitig So was unmodernes wie Java schafft doch nicht mehrere Dinge gleichzeitig Warum kann Swing nicht gleichzeitig Malen und Denken? Ist Swing doch ein Mann?

Agenda ● Problemstellung ● Java ist langsam ● Swing ist langsam ● Threads entwirrt ● Lösungen ● Profiler ● Threading sinnvoll einsetzen ● Tweaking the VM

Profiler Zunächst ein Problem lösen, dann die Performance optimieren > Grundlegende Architekturüberlegungen aber nicht vergessen → Skalierbarkeit Mit dem Profiler prüfen, ob es ein Heap/gc()- Problem oder ein CPU Problem ist Hotspots mit dem Profiler finden, damit man nicht an der falschen Stelle rumdoktert

Profiler

Agenda ● Problemstellung ● Java ist langsam ● Swing ist langsam ● Threads entwirrt ● Lösungen ● Profiler ● Threading sinnvoll einsetzen ● Tweaking the VM

Threading - Swing Schwerpunkt Swing > Warum nur einen Event-Dispatcher-Thread? > RepaintMananger und seine Millionen Threads > Schwergewichtigen Thread starten oder nicht? SwingWorker > Seit Java 6 direkt dabei > > Sehr einfach, super integriert in Swing, vielseitig einsetzbar

Threading - Swing Schwerpunkt Swing > Warum nur einen Event-Dispatcher-Thread? > Keine synchronized Monitore!  Seit je her in jeder Sprache der Flaschenhals und beliebtes Einfalltor für Deadlocks  Mit Graphics-Pipelines (DirectDraw, OpenGL) sowieso kaum sinnvoll vom Anwender ansteuerbar > RepaintMananger und seine Millionen Threads > Exakt vom Swing-Backend gesteuerter Thread-Pool  Kann sauber mit Graphics-Device synchronisiert werden  Arbeitet mit oder ohne Double-Buffering  Paint-Buffer kann direkt im Grafikspeicher liegen, weil Swing die Hoheit über die Thread-Synchronisation hat

Threading – Swing - SwingWorker SwingWorker > Pros > Sehr einfach > Super integriert in Swing > Vielseitig einsetzbar > Cons > Worker Threads nicht konfigurierbar > Reihenfolge der Abarbeitung nicht definiert

Threading – Swing - SwingWorker SwingWorker > Pros > Sehr einfach final JLabel label; class MeaningOfLifeFinder extends SwingWorker public String doInBackground() { return findTheMeaningOfLife(); protected void done() { try { label.setText(get()); } catch (Exception ignore) { } (new MeaningOfLifeFinder()).execute();

Threading – Swing - SwingWorker SwingWorker > Pros > Super integriert in Swing // Always called in Event Dispatcher protected void done() { try { label.setText(get()); } catch (Exception ignore) { } ● getPropertyChangeSupport() ● add- & removePropertyChangeListener

Threading – Swing - SwingWorker SwingWorker > Pros > Vielseitig einsetzbar JTextArea textArea = new JTextArea(); final JProgressBar progressBar = new JProgressBar(0, 100); PrimeNumbersTask task = new PrimeNumbersTask(textArea, N); task.addPropertyChangeListener( new PropertyChangeListener() { public void propertyChange(PropertyChangeEvent evt) { if ("progress".equals(evt.getPropertyName())) { progressBar.setValue((Integer)evt.getNewValue()); } }); task.execute(); System.out.println(task.get()); //prints all prime numbers we have got

Threading – Swing – SwingWorker

Threading – Swing - SwingWorker SwingWorker > Cons > Worker Threads nicht konfigurierbar  Anzahl der WorkerThreads aus den Thread-Pool ist weder dokumentiert noch zu verändern > Reihenfolge der Abarbeitung nicht definiert  WorkerThreads können nicht in Workflows verkettet werden (nur statisch über blockierende get()-Aufrufe)

Threading – Swing – SwingWorker Last word to Swing Threads: >

Threading - NetBeans Schwerpunkt Swing, NetBeans ist Swing! > Event-Dispatcher-Thread, überall RequestProcessor ProgressFactory und ProgressHandle

Threading – NetBeans - RequestProcesor RequestProcessor > Pros > Existiert schon sehr lange in der NetBeans API > Jeder RequestProcessor ist sein eigener ThreadPool > Größe des ThreadPool (Througput) ist von 1 bis n konfigurierbar (1 = serielle Abarbeitung) > Verwendet Thread.isInterrupted() für Terminierung > Arbeitet mit pure Runnable > Hat einen einfachen Scheduler > Cons > Einiges an Deprecated Methods > Etwas unübersichtlicher Aufbau durch mehr Klassen > Keine Verbindung zum EDT

Threading – NetBeans - RequestProcesor RequestProcessor > Pros > Jeder RequestProcessor ist sein eigener ThreadPool > Größe des ThreadPool (Througput) ist von 1 bis n konfigurierbar (1 = serielle Abarbeitung) new RequestProcessor(String name) Creates a new named RequestProcessor with throughput 1. new RequestProcessor(String name, int throughput) Creates a new named RequestProcessor with defined throughput.

Threading – NetBeans - RequestProcesor RequestProcessor > Pros > Verwendet Thread.isInterrupted() für Terminierung > Arbeitet mit pure Runnable new RequestProcessor(String name, int throughput, boolean interruptThread) Creates a new named RequestProcessor with defined throughput which can support interruption of the thread the processor runs in. RP.post(new Runnable() { public void run () { while (veryLongTimeLook) { doAPieceOfIt (); if (Thread.interrupted ()) return; } });

Threading – NetBeans - RequestProcesor RequestProcessor > Pros > Hat einen einfachen Scheduler schedule(Callable callable, long delay, TimeUnit unit) schedule(Runnable command, long delay, TimeUnit unit) scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit) scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit)

Threading – NetBeans - RequestProcesor RequestProcessor > Cons > Einiges an Deprecated Methods > Etwas unübersichtlicher Aufbau durch mehr Klassen > Keine direkte Verbindung zum EDT - Gewachsen, einige Methoden sollten nicht verwendet werden (JavaDoc lesen) - Man muss mit RequestProcessor, RequestProcessor.Task, Runnable, ScheduledFuture und Future arbeiten (dafür aber sehr mächtig) - Konkurriert mit Executor (Java Concurrent API)

Threading – RequestProcesor - SwingWorker? RequestProcessor oder SwingWorker? > SwingWorker immer dann, wenn man exakt nur mit Swing-Komponenten zu tun hat und lange Prozesse für die Aktualisierung von Ausgaben in Swing-Komponenten notwendig sind. > RequestProcessor dann, wenn die zu langen Prozesse mit oder ohne Swing-Komponenten verarbeitet werden müssen und Ausgaben nach Swing optional sind (Dann SwingUtilities.invoke(Later)) > RequestProcessor dann, wenn man definierte Throughputs benötigt, wiederkehrende Tasks ansteuern will oder Tasks zu bestimmten Zeiten ausführen will > RequestProcessor dann, wenn man ProgressHandle und der Möglichkeit arbeiten will, Tasks abzubrechen (Cancellable).

Threading RequestProcesor-ExecutorService? RequestProcessor oder ExecutorService? > ExecutorService + Executor + ThreadPool-Implementationen aus der Java Concurrent API und RequestProcessor sind im Prinzip das gleiche. > RequestProcessor ist ein ScheduledExecutorService und implementiert die Methoden aus der Java Concurrent API > Geschmackssache.

Threading – NetBeans - Progress ProgressFactory und ProgressHandleFactory > Progress API bietet umfangreiches Werkzeug, um alle Threads komfortabel im UI anzuzegen und zu steuern > ProgressHandleFactory > Erzeugt ProgressHandle-Objekte > ProgressHandle > Steuert die Ausgabe einer UI-Komponente und darf nie im EventDispatcherThread aufgerufen werden > ProgressUtils > Helper-Klasse, um blockierende Prozesse mit Dialogen auszuführen (modale Prozesse)

Threading – NetBeans - Progress ProgressHandleFactory > createHandle(String displayName, Action linkOutput) > Create a progress ui handle for a long lasting task. > createHandle(String displayName, Cancellable allowToCancel, Action linkOutput) > Create a cancellable progress ui handle for a long lasting task. > createProgressComponent(ProgressHandle handle) > Get the progress bar component for use in custom dialogs, the task won't show in the progress bar anymore.

Threading – NetBeans - Progress ProgressHandle > setInitialDelay(int milliseconds) > start() oder start(steps) > progress (String nachricht, int step) > switchToDeterminate oder switchToIndeterminate() > setDisplayName (String displayName) > finish()

Threading – NetBeans - Progress ProgressUtils > Ein paar nützliche Methoden um Dialoge mit Progress-UI Komponente anzuzeigen, um dabei gleichzeitig den aktuellen EDT komplett modal zu blocken. > d.h., User kann die Anwendung so lange nicht bedienen > aber: Ausgaben bleiben weiterhin möglich (keine einfrieren der Anwendung) > showProgressDialogAndRun, showProgressDialogAndRunLater runOffEventDispatchThread

Agenda ● Problemstellung ● Java ist langsam ● Swing ist langsam ● Threads entwirrt ● Lösungen ● Profiler ● Threading sinnvoll einsetzen ● Tweaking the VM

Tweaking the VM Internet ressources: > Use Server Hotspot instead of Client Hotspot > In your JDK > Tuning Garbage Collection in Java VM > > Aber: > Nicht übertreiben. Die beste Arbeit macht die VM mit automatisch ermittelten Parametern

Fragen & Antworten