profiling result panic: javax.swing.SystemEventQueueUtilities.queueComponentWorkRequest 56% of time spent?
Dimitri Ognibene
did anyone has ever had the same problem with
javax.swing.SystemEventQueueUtilities.queueComponentWorkRequest?
it's a multi-thread issue?
how can i address it?
thanks to all
dimitri
ps if more info are needed pleas ask
Chris Uppal
> why?
Why what ?
Oh, you mean the long question that you've put in the thread title. Please
don't do that, it makes posts difficult to read.
> did anyone has ever had the same problem with
> javax.swing.SystemEventQueueUtilities.queueComponentWorkRequest?
I haven't looked at the logic, but is it possible that all you are seeing is
that the system spends a lot of time idle between repaints ? The user
interface thread /should/ spend most of its time idle, so that will show up as
a hotspot unless the profiler is clever enough to know that wait()s (and other
synchronisation primitives) "don't count".
Put it another way: what reason do you have to suppose this is an issue ?
-- chris
Dimitri Ognibene
I'm sorry for the few detail i've added to the post, however i think
that this is an issue becouse the gui is displaying data from model
modification, the repaint method is triggered by an notifyObservers
called at the end of an heavy method (that of the other post about 2
variants for vector product,
http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/c515e6620ba0a7cd/502bc39588d6cbf1#502bc39588d6cbf1).
this is how I implement autorefresh of data display in my simulator,
and i can turn it on and off by mean of a flag.
when i turn off autorefresh about 80% of time is spent inside that
heavy mathematical method, when i enable autorefresh the time is spent
for 57% in
javax.swing.SystemEventQueueUtilities.queueComponentWorkRequest and
the profiler tells that it is spent inside the method so I think it is
spent in synchronize..
I believed that the repaint manager does merge repaint calls and then
calls javax.swing.SystemEventQueueUtilities.queueComponentWorkRequest
but it doesn't seem to do so..
mmh now perhpas my question is a little more detailed..
Dimitri Ognibene
repaint at most one time in an interval of time..
Do you think that this can be a solution?
Chris Uppal
I think it likely. I tried to track down what's happening with locks inside
that part of AWT/Swing but failed miserably. Still, it seems clear that the
basic problem is that you are issuing too many updates.
I think I suggested earlier (in a different thread) that you should decouple
updating the display from the loop which generates results (copying data freely
in order to do so). I still think that would be the best approach. I.e. your
main loop sticks a copy of the most recent state into a shared location every
now and then (every tenth time around the outer loop for instance), and your
display code uses a Timer to cause itself to update independently at some
frequency which makes sense for you application. I suspect that one update per
second (or so) would be fine, but maybe you need smoother animation, in which
case 5 or 10 times a second might be necessary. Obviously the two update
speeds should be fairly close to each other, but they don't have to be
identical, and you shouldn't have to hold locks on shared variables for more
than the odd nanosecond here and there.
-- chris
Dimitri Ognibene
moment I've added a System.arraycopy.. but the problem is still there..
using the timer solution however had some result..
Chris Uppal
> How can I see if it is a problem due to locks on shared var?
Difficult to know. I believe that some profiling tools have the ability to
show what the contended locks are, but I don't currently have a profiler at
all, so I can't make recommendations.
> at the
> moment I've added a System.arraycopy.. but the problem is still there..
It depends on where the problem is. You own code can be arranged so that there
is only one shared variable[*], and only two synchronised sections at all, both
/very/ short (one to read it, one to write it). You can be certain that /that/
synchronisation isn't an issue.
([*] Assuming that a "snapshot" of the state of the simulation can be expressed
as just one object -- which is always possible, although it may not be
convenient. If not then replace the above by "a small number of shared
variables" and the rest is still true.)
But given your profiling results, it appears that the lock handling within
AWT/Swing is also getting in on the act. I can't see how it's managing it, but
your results are consistent with the idea that a new repaint request can't be
queued (the attempt will block) while your paint() (or paintComponent()) code
is active.
One thing to check is what locks your own paint() (etc) methods hold, and for
how long. If you have made that whole method synchronised then that might well
cause problems.
BTW, please don't be offended, but I think your problems here are coming from
trying too hard to optimise the wrong things. Copying is cheap, holding locks
is not. Similarly, if your simulation generates new data while the display
loop is trying to paint the old stuff, then that just doesn't matter. Finish
displaying the old stuff (which will only be out of date by an inconsequential
margin), and then (on the next tick) go back to the simulation for the most
recent snapshot. You don't need to worry about whether the AWT/Swing code
merges successive update requests, because you are not issuing them fast enough
for that to matter. You don't need to worry about falling behind the
simulation, because at each tick, you are always displaying the most recent
snapshot. The simulation loop is /certainly/ worth putting effort into
optimising. And your actual display code may well benefit from some
profiling/optimisation too. But getting data from the producer to the consumer
should not be enough of a bottleneck to worry about.
-- chris
Dimitri Ognibene
>is only one shared variable[*], and only two synchronised sections at all, both
>/very/ short (one to read it, one to write it). You can be certain that /that/
>synchronisation isn't an issue.
in a separated thread but I've no synchronization on data, because I'm
not interested in the coherence between displayed data, the can be part
of 2 successive steps of elaboration and I would not have any problem
with this.. so the only thing that I do is to notify that a component
of the model updated its status, which is usually a set of
multidimensional arrays.. some display classes are connected as
observers to the model, when they receive the notification the repaint
method is called.. or a timer is started to call repaint.
the paint method of each visualization class read data from one of the
component status and build a the visualization.. i.e. one visualization
takes the position of a graph nodes from the weights of a neural
networks.. calls a method to transform them in 2d position and then
uses another net activation to select color and another one to select
the connections..
not all the components are update at each steps.. and the model and the
visualization are changed often and their status is big.. however all
is update in a serial manner so no synchronization is needed inside the
model.. but I don't know what is the behavior of the system when the
swing thread read data from inside the model.. It's long time (if i
ever was a time) since i've used multithread.
>But given your profiling results, it appears that the lock handling within
>AWT/Swing is also getting in on the act. I can't see how it's managing it, but
>your results are consistent with the idea that a new repaint request can't be
>queued (the attempt will block) while your paint() (or paintComponent()) code
>is active.
>One thing to check is what locks your own paint() (etc) methods hold, and for
>how long. If you have made that whole method synchronised then that might well
>cause problems.
no I've not used the synchronised keyword in all the project..
>BTW, please don't be offended, but I think your problems here are coming from
>trying too hard to optimise the wrong things. Copying is cheap, holding locks
>is not. Similarly, if your simulation generates new data while the display
>loop is trying to paint the old stuff, then that just doesn't matter.
You are right but i believed that the repaint call would be merged in
one call, and I've not a display loop, the display is triggered by the
model.. any visualization that is related to the model is notified of
the change and if it is in autorepaint mode it calls repaint..
Building a snapshot is not so easy.. there are various MB of data and
not all is required to be repainted, and the structure of the data is
somewhat complex.. it is not a simple call to system.arraycopy..
perhaps.. one way could be to let the system to only mark as dirty
..and copy to a buffer... to display... but i wouldn't be easier to
stop the algorithm display and continue or not to stop it and
continue..?
>Finish
>displaying the old stuff (which will only be out of date by an inconsequential
>margin), and then (on the next tick) go back to the simulation for the most
>recent snapshot. You don't need to worry about whether the AWT/Swing code
>merges successive update requests, because you are not issuing them fast enough
>for that to matter. You don't need to worry about falling behind the
>simulation, because at each tick, you are always displaying the most recent
>snapshot. The simulation loop is /certainly/ worth putting effort into
>optimising. And your actual display code may well benefit from some
>profiling/optimisation too. But getting data from the producer to the consumer
>should not be enough of a bottleneck to worry about.
You are right.. but i was thinking about some kind of errorr in the
repaintmanager..
At last the question is:
my system doesn't need to synch the display code with the symulation
steps, so I've not used any synchronized method... only call to repaint
when needed.. and I'm now using for some classes a timer that is
started by the notification and at last call repaint.. it seem to work
for heavy weight visualizations.. do you think that with a complex
structure like that of mine simulator, is coping data still usefull?
thanks
dimitri