«

"Manish Hatwalne" wrote:

> What are general tips or golden rules to speed up your Swing
> application?

Do not block the EDT.

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

Manish Hatwalne wrote:

> 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.


--
Regards,
Christophe Vanfleteren

Manish Hatwalne wrote:

> 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,
--
Karsten Lentzsch
www.JGoodies.com - Java User Interface Design

On Tue, 28 Oct 2003 00:10:31 +0530, Manish Hatwalne
<> wrote:

> 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.

--
Daniel Dyer
Empathy Software


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

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?

"Daniel Dyer" <> wrote in message
news...
> On Tue, 28 Oct 2003 00:10:31 +0530, Manish Hatwalne
> <> wrote:
>
> > 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.
>
> --
> Daniel Dyer
> Empathy Software
>
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 100,000 Newsgroups - 19 Different Servers! =-----

On Tue, 28 Oct 2003 17:33:38 GMT, Phil... <> wrote:

> 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.

--
Daniel Dyer
Empathy Software


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----