Swing + Thread + Performance + JDK 1.5 question
Using JDK 1.5 I am experiencing performance degredation in one element of my interface.
The application performs a test action (Could be connecting to a database could be doing something else doesn't really matter) repetetively and runs (n) number of them approximately simultaneously.
A manager thread controls the entire process and is executed from the EDT as a result of an ActionPerformed of a button. Within the managing thread, (n) "worker" threads (Not an implementation of SwingWorker) are executed. These child threads update the DefaultModel of a JList on an as needed basis so that the user can watch the running threads in action. (This is really more to ensure that no individual thread gets into a hung state but that's a different topic)
The problem is that over time of letting it run the painting of the JList will start to degrade and the JList will go blank for several seconds at a time. The rest of the user interface (the slider that controls the number of concurrent threads and the stop button that stops the main thread and waits for the rest to die off for example) seem to work fine most of the time. (They have occasionally gotten sluggish as well though that's rare). The only real problem seems to be that the paint of the JList and the list renderer derived components within it gets slow over time.
Comments thoughts or suggestions most welcome.
Regards,
PS.
# 3
Perhaps I should add that as threads are created (added to the thread pool) an associated monitor is added to the JList model. When the thread finishes its work it's last act is to remove itself from the pool and from the JList model. Thusly if the throttle is set to have 20 concurrent threads, the pool and the JList contain respectively, 20 threads and 20 thread monitors.
PS.
# 4
> Are the updates of the list model from the child threads being done in the EDT?
>> They're being done from the child threads
So the answer is, no.
Launching a Thread from the EDT has nothing to do with the code executing in the EDT.
Try wrapping the update to the ListModel in a SwingUtilities.invokeLater() so the update is done in the EDT.
# 5
camickr,
Good call. that was what it wanted. Runs like a scalded dog without any flicker at this point.
Wrapped the calls that would result in adding a ThreadMonitor, Removing a ThreadMonitor or updating a ThreadMonitor with
SwingUtilities.invokeLater(new Runnable(){
public void run(){
// do something here
}
}) ;
and the ui is very well mannered now.
There is one gotcha for anyone who comes along after and reads this thread. This change increases the app to use more heap space and at full throttle I was able to bring the application to its knees.
Just something to be aware of.
camickr, once again thank you.
PS.
# 6
> This change increases the app to use more heap space
Don't know if it will make any difference, but try creating a single Runnable and then just keep passing the same Runnable object to the invokeLater() method.
It should at least minimize object creation and garbage collection.
