Home/ Questions/Q 590687
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:33:21+00:00

I’m coding a JTable that is capable of handling frequent updates. Typically this JTable

  • 0

I’m coding a JTable that is capable of handling frequent updates. Typically this JTable has ~1000 rows of data, and some of the columns will update frequently because their values are derived from stock price which moves a lot during market hours.

The problem I’m facing is that when large # of rows (e.g. 80%) are updating, the JTable become very slow for 20-30 seconds or so, which the profiler shows that the EDT thread is extremely busy, handling tableChanged calls.

I try to collapse the changes by
1) suppressing fireTableCellUpdated
2) If there are <= 50 rows changes, call fireTableRowUpdate on individual rows
3) If there > 50 rows of changes, calling fireTableDataChanged for the entire table.

It’s better, but still slow when there are frequent updates, my understanding is that fireTableDataChanged is slow as well. So if data updates frequent enough, fireTableDataChanged will be called frequently, and the GUI will feel sluggish.

Can someone experienced in this subject recommend a best practice in using fireTableRowsUpdate,
fireTableDataChanged and fireTableStructureChanged to improve GUI liveliness and performance? If you have pointers to sample codes that address this problem it’ll be even better.

Many thanks

Anthony Si

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve done that and indeed, even on beefy setups the default JTable perfs are terribly bad. But all hope is not lost: using (quite) a few tricks you can get acceptable performances.

    Basically, Oracle has a tutorial precisely for this purpose called the “Christmas tree”.

    Here you go, “How to create frequently updated JTable that perform well”:

    http://www.oracle.com/technetwork/java/christmastree-138396.html

    One of the thing that I found really amazing was to constantly display the memory used: you may want to do that.

    You’ll be amazed at how much needless crap is generated by a default JTable, slowing everything down and making of course the GC trigger way more often than it should.

    Then start implementing all the tricks given in the link I gave you and you’ll see that everything shall run much smoother. I’m now running very complex and “constantly updated” JTable and all is fine now 🙂

    But yup, besides for the simplest case and tiny amounts of data, the default JTable implementation is really terribly bad.

    • 0