• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 281
  • Last Modified:

Best approach to updating JTable rapidly

I've been having a problem with my program getting bogged down when many updates happen at once.  

I have a table model that has a method in it

I've tried calling this many different ways.

I have a thread receiving new data objects which stores them in a buffer, then I process the buffer in another thread, which basically gets an object from the buffer and calls updateTable in the table model with the object from the buffer.

The updateTable method takes the  data and calls setValueAt(.......)

I've tried using a swingWorker for each call to the updateTable method in the processing thread.

Everything seems to work, until I get a hundred updates at once, then things come to a crawl.

It would make sense if I thought I was creating a hundred worker threads when I get the hundred updates, but I've read the swing worker uses a pool of 10 threads as a default.

I tried creating my own thread pool of 5 threads, which worked however it ran even slower.

Maybe I'm not supposed to be calling setValueAt in the model?

This is all part of a bigger program so I don't have stand alone code that runs which I can post, but I can make one tomorrow if the information I've given is not enough information.
1 Solution

check this article dealing with tihuis issue of many updates to JTable
>> but I can make one tomorrow if the information I've given is not enough information.

That might be useful - for you AND us
If your TableModel extends DefaultTableModel (AbstractTM?) I think the setValueAt() method will fire events to update the JTable's UI, meaning every update you make triggers a re-render which is likely what is bogging your code down.  You are probably better off changing the underlying data structure in bulk (without using the setValueAt() method) and then calling the appropriate fireTableXxx() event handler to notify the table your data has been updated.
Read that link about Christams tree above - it has all that advice about accumulating changes and much more about dealing with the tables which undergo fast changes
dev110Author Commented:
I was having trouble duplicating the problem with a stand alone program extraced from
my actual program, which is actually a plugin to another software.

I did end up finding the culprit of my CPU usage, which turned out to be a loop that was comparing against the size of the table. I've reworked that loop with use of some hashmaps
and all is much faster now.

I've read  the link about the Christmas tree and implemented  some of the techniques referenced in the link. I was able to lower the CPU usage a little bit more.

Thanks for  all of  your responses,  I know I didn't give much to go on without posting any code.

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now