profiling result panic: javax.swing.SystemEventQueueUtilities.queueComponentWorkRequest 56% of time

Discussion in 'Java' started by Dimitri Ognibene, Apr 23, 2006.

  1. why?
    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
    Dimitri Ognibene, Apr 23, 2006
    #1
    1. Advertising

  2. Dimitri Ognibene

    Chris Uppal Guest

    Dimitri Ognibene wrote:

    > 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
    Chris Uppal, Apr 24, 2006
    #2
    1. Advertising

  3. hi again chris,
    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...620ba0a7cd/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, Apr 24, 2006
    #3
  4. I'm tryng to move the call to repaint to another thread which calls
    repaint at most one time in an interval of time..
    Do you think that this can be a solution?
    Dimitri Ognibene, Apr 24, 2006
    #4
  5. Dimitri Ognibene

    Chris Uppal Guest

    Dimitri Ognibene wrote:

    > I'm tryng to move the call to repaint to another thread which calls
    > repaint at most one time in an interval of time..
    > Do you think that this can be a solution?


    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
    Chris Uppal, Apr 25, 2006
    #5
  6. How can I see if it is a problem due to locks on shared var? at the
    moment I've added a System.arraycopy.. but the problem is still there..

    using the timer solution however had some result..
    Dimitri Ognibene, Apr 25, 2006
    #6
  7. Dimitri Ognibene

    Chris Uppal Guest

    Dimitri Ognibene wrote:

    > 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
    Chris Uppal, Apr 25, 2006
    #7
  8. >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.

    My model, the various mathematical algorithm classes, does their work
    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
    Dimitri Ognibene, Apr 25, 2006
    #8
    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. Replies:
    1
    Views:
    690
    Esmond Pitt
    Mar 27, 2005
  2. lizard
    Replies:
    0
    Views:
    1,749
    lizard
    Jan 30, 2006
  3. Andrew Thompson

    javax.servlet and javax.servlet.http

    Andrew Thompson, Apr 24, 2007, in forum: Java
    Replies:
    1
    Views:
    634
    newbie_at_tomcat
    Apr 25, 2007
  4. S.T
    Replies:
    2
    Views:
    563
  5. Michael Tan
    Replies:
    32
    Views:
    927
    Ara.T.Howard
    Jul 21, 2005
Loading...

Share This Page