When developing a Java GUI application (SWT or Swing based, should not matter), how to best profile the responsiveness, e.g. what consumes the time if the application feel sluggish on certain operations like clicking a button until something happens. The problem is in my understanding that the delays are quite low (usually < 0.5s) and hence hard to measure, because the most profilers I know you need to start and stop later.
The problem with profiling UI applications is that calls on the event dispatch thread (EDT) often originate from other threads or trigger background operations that eventually call something on the EDT. This can make it difficult to see the effects of a user action separately.
JProfiler has a feature called "Async tracking" that can track calls into the event dispatch threads of both AWT and SWT:
You have to profile with instrumentation and enable tracking:
Then you record CPU data and perform the actions that trigger actions on the EDT:
Finally, you click on "Inline async executions" to see the call tree across thread boundaries:
Disclaimer: My company develops JProfiler.
YourKit Java Profiler has built-in probe which automatically records all AWT/Swing events longer than 0.3 second, which can cause UI irresponsiveness:
https://www.yourkit.com/docs/java/help/awtevents.jsp
Disclaimer: I work for YourKit
Related
I have an android application where I am performing some operations in background threads. For some reason my app becomes extremely slow and unresponsive after being used for few minutes. I am suspecting that it is because of some background thread, so I want to monitor the threads that my app is creating. However, I couldn't find a suitable tool where I can see and monitor those threads. Is there any way I monitor the background threads at runtime.
You can use DDMS to monitor the Threads at runtime. Look at the DDMS document .
I'm not sure about how can you see threads but you can try following
Enable Strict mode in developer setting, you will see screen flashing red on heavy operations.
Add logs to your thread and print progress with time, by this you can know which method is taking time.
More on strict mode here:
https://developer.android.com/reference/android/os/StrictMode.html
You can use the build in tools to profile the app.
See here : https://developer.android.com/studio/profile/traceview.html
I've just started programming in Java, and I'm interested in how computers distribute their CPU load. I have made a very basic program that creates a window and makes a box and line move. While testing this, I looked at Task Manager; Task manager said I was using ~1% of my CPUs. however, when I ran my program, the CPU usage went up to ~36% (I only started the program, nothing else). Can anyone tell me what is going on here, please?
You think that your program has only one thread, but in reality every Java program has lots of threads. GUI apps have the Event Dispatch Thread, garbage collection has its own thread etc. You can use a profiler (like the VisualVM that is in the JDK) to see all the threads in your app.
Or you can see them programmatically, see Get a List of all Threads currently running in Java
Recently I have read in a book that Concurrency is a fundamental tool for multiprocessor programming.
Than how is it useful for single core processor?
Concurrency is a fundamental tool for multiprocessor programming.
Yes, but it can also help in other areas. For instance, concurrency can also improve throughput on a single core system if the cpu is not the bottleneck (for instance, because the threads spend most of their time waiting for I/O from disk or the network).
Concurrency is helpful whenever there are multiple tasks that need to be run simultaneously. A very common example is in GUI programming; you don't want your UI to freeze up while the program waits for data to load from the disk or network, so you have a thread that just manages the UI elements (called the Event Dispatch Thread in Swing/AWT), and background threads that take care of communications or long-running calculations. The OS swaps them back and forth to make sure that the UI gets redrawn while other tasks are still active.
Being able to switch between running thread is useful for the perception of performance on a single core processor. In many systems, the graphical parts of the UI is updated by another thread than the one doing the work. It would be frustrating for the user to not have any feedback while a long task is running. Another useful application of concurrency on a single core, would be to start a long running task with low priority while the user is free to do other stuff at the same time.
In my application, some process that is started in AWT's Event Dispatching Thread (EDT) may be interrupted under particular circumstances. Then it waits for input from the user. Alas, as the process is located in the EDT, the whole application freezes and the user is unable to relaunch the process, thus creating a deadlock. Is there any way to interrupt the EDT and lauch a new event pump from another thread ? Then the user would be able to interact with the UI.
What I am trying to do looks more or less like opening a modal dialog, except that I don't want a dialog because my component is complex. I'd rather display it right inside my root pane. So I had a look at how it's done in java.awt.Dialog, and had a pretty good understanding of it, but the most important classes that are used (EventDispatchThread, SequencedEvent, ...) are protected and therefore inaccessible for me.
Thank you all for your answers.
I'll be more specific. I am actually working on an application which embeds a homegrown scripting language. I am developing a debugger for this language. The debugger (as all debuggers) would stop the script execution whenever a breakpoint is met. The scripted processes can be triggered from many places (including from the EDT) in the code so taking the the process out of the EDT is not an option. I'd like the debugger UI to be embedded in the application (in a side pane to be precise). So when a breakpoint is met I would need the current thread (possibly the EDT, not to say mainly) to be interrupted and at least the debugger's UI should still be responsive. Also I am developing atop of the JDK 1.4 so no way to use JDK7 alas.
What I am currently doing is opening a JDialog with the debugger embedded. It all works fine but as I said I am not fully satisfied by this solution because I would really want my debugger to be embedded right in my main window.
If you are using JDK7, you can use the SecondaryLoop interface. An instance of this interface can be created through the EventQueue.createSecondaryLoop method
There was an informative blog post with an example but the server seems to be offline for the moment.
A small edit as I am still not fully sure I understand your question.
If you want to wait for user input from a worker thread, you can use the SwingUtilities.invokeAndWait method and use a blocking method (e.g. show a JOptionPane to retrieve user input). Due to the invokeAndWait your worker thread will be stopped until the Runnable on the EDT is processed. If you use a blocking method on the EDT to retrieve the user input that Runnable will only be finished when the user has provided his/her input
We are experiencing a bug we cannot track down where something is freezing up our swing thread (it's been almost 2 weeks now and no real results) - we are experienced Swing programmers but we have a huge program and believe it to be in some of the legacy code
I am wondering, is there any way outside of editing the actual EventQueue class in the JDK which will allow us to view all pieces of our code currently running on the Event Dispatch Thread - maybe some type of tool which will allow us to view things as they enter or leave the event dispatch thread?
One interesting approach is to extend EventQueue and push() it, as shown here.
Logging everything that passes through the Event Dispatch Thread seems a cumbersome way to diagnose a freeze. Wouldn't it be easier to wait until the problem occurs, and then ask the Event Dispatch Thread what it's doing now? One way to do this is to enable JMX monitoring, connect to your running process with a JMX client such a VisualVM (which ships with the JDK), wait for the problem to occur, and then take a thread dump.
In case you still wish to log everything the Event Dispatch Thread is doing, you can do this by:
In Eclipse, launch the application in debug mode.
Create a breakpoint on EventQueue.dispatchEvent, right-click it, select "properties", check "condition", and enter the following "condition":
System.out.println(arg0);
return false;
It might be good idea to try BTrace to instrument the EventQueue and capture stack traces each time something gets added. I think the latest VisualVM has plugins that will allow you to instrument a running JVM with a BTrace script.
If you're using the Oracle JRE, there is a TracedEventQueue included already. You can install it as mentioned before:
EventQueue eventQueue = Toolkit.getDefaultToolkit().getSystemEventQueue();
eventQueue.push(new TracedEventQueue());
Note, this will output a lot of output...