Speeding up Swing application

Discussion in 'Java' started by Harald Hein, Oct 27, 2003.

  1. Harald Hein

    Harald Hein Guest

    "Manish Hatwalne" wrote:

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


    Do not block the EDT.
    Harald Hein, Oct 27, 2003
    #1
    1. Advertising

  2. 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, Oct 27, 2003
    #2
    1. Advertising

  3. 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
    Christophe Vanfleteren, Oct 27, 2003
    #3
  4. 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
    Karsten Lentzsch, Oct 27, 2003
    #4
  5. Harald Hein

    Daniel Dyer Guest

    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! =-----
    Daniel Dyer, Oct 28, 2003
    #5
  6. Harald Hein

    Phil... Guest

    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:eek:...
    > 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! =-----
    Phil..., Oct 28, 2003
    #6
  7. Harald Hein

    Daniel Dyer Guest

    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! =-----
    Daniel Dyer, Oct 28, 2003
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Big Daddy

    Java 1.2 Swing vs. Java 1.5 Swing

    Big Daddy, Apr 15, 2005, in forum: Java
    Replies:
    2
    Views:
    499
    Pete Barrett
    Apr 16, 2005
  2. mkrause
    Replies:
    0
    Views:
    670
    mkrause
    May 6, 2005
  3. lizard
    Replies:
    0
    Views:
    1,763
    lizard
    Jan 30, 2006
  4. S.T
    Replies:
    2
    Views:
    578
  5. Petyr David

    Speeding up an application - general rules

    Petyr David, Dec 22, 2006, in forum: Perl Misc
    Replies:
    7
    Views:
    114
    Petyr David
    Dec 24, 2006
Loading...

Share This Page