Speeding up Swing application

M

Manish Hatwalne

What are general tips or golden rules to speed up your Swing application? In
other words, where exactly should you look for if instructed to "speed up"
your swing application. (SWT and AWT are not the available alternatives!
:))

TIA,
- Manish
 
C

Christophe Vanfleteren

Manish said:
What are general tips or golden rules to speed up your Swing application?
In other words, where exactly should you look for if instructed to "speed
up" your swing application. (SWT and AWT are not the available
alternatives!
:))

TIA,
- Manish

Try to avoid having longrunning code in your event handler, in other words:
run any operation that takes a while to execute in a separate thread if
possible. Look at Swingworker.

If you have enough memory, you can also try to preload and reuse common used
dialogs instead of creating them just when necessary.

If your apps uses lots of memory, set a bigger maximum heap for the program,
eg. "java -Xmx128" to use a maximum of 128MB of ram instead of the default
64MB.
 
K

Karsten Lentzsch

Manish said:
What are general tips or golden rules to speed up your
Swing application? In other words, where exactly should you
look for if instructed to "speed up" your swing application.
[...]

1) Favor responsiveness over speed!
Let the user see or feel a response immediately;
hence do not block the Event dispatching thread.
Know the Swing Worker or Foxtrot.

2) Construct lazily and prepare eagerly!
Construct only objects and panels that are required.
To comply with rule 1) prepare panels and objects
in a background thread so they are ready when needed.

3) Enable the developers to analyze the program!
To fix performance problems, the team should be
able to find and understand them. A profiler helps.

Regarding tip 2) you may consider trying JDiskReport,
where you can change the eager preparation in the prefs.
The effect can be best observed with the file chooser
in Windows look&feel. If preparation is enabled, the
file chooser pops up almost immediately; if disabled,
it can take up to 2 seconds on a 2GHz Pentium.
You can observe the preparation (and infer the lazy
construction) if you enable logging. In a console:
java -DlogLevel=info -jar jdiskreport-1.1.1.jar

The tool is available for free at
http://www.jgoodies.com/freeware/jdiskreport/

Hope this helps,
 
D

Daniel Dyer

What are general tips or golden rules to speed up your Swing
application? In
other words, where exactly should you look for if instructed to "speed
up"
your swing application. (SWT and AWT are not the available alternatives!
:))

TIA,
- Manish

Probably a question that should be asked on comp.lang.java.gui, but here
goes:

If you have an existing application that you are trying to tune you really
need a good profiler to tell you where the bottle necks are, but here's a
few tips to get you started (in no particular order):

1. Responsiveness
Without actually improving the performance of your code you can make your
GUI appear faster by providing feedback to the user. Appropriate use of
progress bars and wait cursors will at least let the user know that
something is happening and there are articles that claim the user
perceives a 20% performance increase from this alone. I don't know if
this is accurate but the user will be less irritated if they know what's
happening.

2. Data Models
When using components that require you to provide a data model (such as
JTable, JTree or JList) make sure you have an efficient one. For JTables
in particular, it is rarely a good idea to use the default model. The
getValueAt method is a good place to start looking, this needs to be a
cheap call.

3. Renderers
I have seen some pretty horrific custom cell rendering code for tables.
The cell renderers are invoked for every visible cell in the table each
time the table is repainted. This can result in a ridiculous number of
calls to the getTableCellRendererComponent method, so the rendering code
needs to be as fast as possible. Only do the stuff that is absolutely
necessary in the renderer call (i.e. that stuff that changes from cell to
cell). Prepare everything else in advance. Use caching to avoid
repeating calculations or object allocation. You can usually write your
renderer code in such a way that you don't have to allocate any objects in
the actual renderer call. This advice applies to other components that
may use custom renderers, such as JTree, JLists, JComboBoxes, etc., as
well as to JTables.

4. Custom Painting
If you implement your own painting code for a component it is a good idea
to profile it. Much of the advice for renderers applies for other
painting as well. Your paint routines will be invoked frequently.

5. Garbage Collection
Tuning the settings on your VM's garbage collector will help eliminate
long pauses (possibly at the expense of overall throughput). For GUIs
this is important as a long pause with the application being unresponsive
will irritate the user.

6. Threading
Intelligent use of threads can make a big difference to the responsiveness
and therefore the perceived performance of your GUI. Don't do everything
on the event dispatch thread, consider delegating expensive processing
that doesn't directly update the GUI to other threads. You will need to
be aware of the threading issues in Swing and make appropriate use of the
methods in SwingUtilities such as invokeLater and invokeAndWait.

Hope that helps. Not all of these will be issues in your GUI, you really
need a profiler such as JProbe, or at least put some timing code in your
classes, to make sure you are optimising the right areas.


Dan.
 
P

Phil...

with regard to #3, don't you need to repaint
all these cells because the one that is changed
might cause that cell to change size?
 
D

Daniel Dyer

with regard to #3, don't you need to repaint
all these cells because the one that is changed
might cause that cell to change size?

Sorry, my posting was ambiguous. I didn't mean the fact that every cell
was repainted was the problem. I meant that you need to take this fact
into consideration so that you understand how much processing is actually
being done. That's why you don't want to repeat things that don't need to
be done more than once.

Dan.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top