Measuring “busyness” of the event dispatching thread

Question

I would like to measure the "busyness" of my Event Dispatching Thread. One possible idea is to set up a background thread that does something like:

while(true) {
    final long[] end = new long[1]; // Array to get stuff out from Runnable.
    long start = System.nanoTime();
    EventQueue.invokeAndWait(new Runnable() {
        public void run() {
            end[0] = System.nanoTime(); 
        }
    });
    long queueTimeNs = end[0] - start;
    // Report the queue time somewhere.
    Thread.sleep(100); // Poll the EDT < 10 times/s.
}

The idea is to measure how long it takes from sending an event to the EDT to it getting dispatched. This would give a rough idea about the responsiveness of the UI.

Does this make any sense? Is there some more standard way to do something similar?

Answer 1

I use an excellent tool for this : SwingExplorer. It allows you to inspect your Swing components, to see how they are drawn, to detect the EDT violations, and to detect the hangs of the EDT. Basically, you enter a duration value in milliseconds, and then you play with your app. When the EDT hangs for more than this duration, the hang is logged in the tool's UI.

The official site is https://swingexplorer.dev.java.net, but it seems to be down at the moment I write this answer. You can find a plugin for Eclipse and NetBeans, and you can also find swingexplorer on a maven repository, if you use maven (sorry, I can't find a link for the moment)

At least the repository is still available : cvs -d :pserver:guest:guest@cvs.dev.java.net:/shared/data/ccvs/repository co swingexplorer

Edit

I looked at the source code of Swing explorer, and it appears that they wrote a custom EventQueue to inspect the EDT behavior. The code seems to be related to another project, SwingHelper.

Edit 2

The project's site will come back soon at http://java.net/projects/swingexplorer

Answer 2

I think your appraoch is close to ideal in measuring "responsiveness" since it takes into account both the actual amount of work done in the EDT (possibly way too much in a badly-designed app) and the machine's ability to do that work.

BTW, I once tried to replace/reroute the EDT, but after many hours I found that it was impossible even when recklessly using reflection to access private fields of implementation classes. In the end, everything hinged on a local object being waited on, which was impossible to get a hold of.

I suspect that for the same reason it's not possible to intercept the EDT to get information such as the number of events processed (which was my first idea for a metric you could use).