Why Latency Profiling?
When developers need to improve the performance of their applications, they usually use one of the many existing profilers. These profilers generally capture a profile that represents the execution time spent in each method. The developer can thus focus her optimization efforts on the methods that consume the most time. We argue that this type of profile is insufficient for tuning interactive applications. Interactive applications respond to user events, such as mouse clicks and key presses. The perceived performance of interactive applications is directly related to the response time of the program, but not necessarily to the overall time spent in various methods.
What is Latency Profiling?
We thus devised listener latency profiling, a profiling approach with two distinctive characteristics. First, we call it latency profiling because it helps developers to find long latency operations. Second, we call it listener profiling because it abstracts away from method-level profiles to compute the latency of the various listeners. This allows a developer to reason about performance with respect to listeners, also called observers, the high level abstraction at the core of interactive object-oriented applications.
Performance Characterization
The above figure shows the perceptible performance of NetBeans and our own GUI application, LiLa Viewer. It includes three curves for each benchmark. The x-axis corresponds to the latency, and the y-axis corresponds to the number of requests that took longer than the given latency, per second of working time. Working time is the time the system spends handling user requests. We normalize by working time to be able to compare different distributions. We chose working time (instead e.g. end-to-end trace duration) for fairness: it would be unfair to divide by a long end-to-end time, if most of that time the system was idle, waiting for a user request.
We notice that NetBeans has a better performance than LiLa: Every second, LiLa causes between 2 and 2.5 episodes that are longer than the 100 ms perceptibility threshold. NetBeans, on the other hand, only causes between 0.3 and 1 such episodes. These results confirm our expectations: The professional-grade NetBeans application, which had been especially optimized for interactive performance, outperforms our prototype-quality LiLa Viewer.
Finding Causes
Visualization of the Listener Latency Profile
Our profiler points out several causes for the inferior performance of the LiLa Viewer; the most significant is a listener reacting to changes in a table model. The listener sorts the rows whenever the underlying model changes, which is expensive with large models. Given this information, we can now optimize this task to improve the perceptible performance of the LiLa Viewer.