Viewing performance bottlenecks
Performance bottlenecks can be quickly identified by using the Execution Statistics view and the Method Invocation view.
Identifying the packages with a high execution time
In the Profiling Monitor view, select the monitor or agent.
Right-click and select Open with > Execution Statistics. The Execution Statistics view opens.
Click Package from the toolbar to display the class statistics.
To analyze performance data, you want to look at the time related columns. Right-click and select Choose columns.
Select Base Time, Average Base Time, Cumulative Time and Calls.
Base Time: The amount of time (in seconds) the method has taken to execute. NOT including the execution time of any other methods called from this method.
Average Base Time: The average base time required to execute this method ONCE.
Cumulative Base Time: The amount of time (in seconds) this method took to execute. Including the execution time of any other methods called from this method.
Calls: The number of times this method was invoked.
Click OK. The Execution Statistics view is refreshed with the time columns.
Sort the Base Time column by clicking on the column heading.
Identify the package that has the greatest base time. Open the package tree.
Identify the class or classes with the highest base time.
Examine the performance within the classs identified in further detail by switching to the Class mode.
Identifying the classes within the package with high execution time
Open the Class mode by clicking Class in the toolbar.
In the Class mode, select Choose columns.
Select Base Time, Average Base Time, Cumulative Time and Calls.
Sort the Base Time column by clicking on the column heading.
Identify the class with the greatest Base Time and open the class tree.
Examine which method calls within the class have the greatest Base Time.
Examining the methods within a class to identify high method invocations
The slow performance methods identified in the Execution Statistics view can be examined in more detail to further pinpoint the source of the bottleneck using the Method Invocations view and table. This view will allow you to see the execution pattern and the differences between invocations of the same method.
To view the methods in the Method Invocation view, follow these steps:
To open the Method Invocation view, right-click on a method and select Show Method Invocation. The Method Invocation view opens.
From the Method Invocation view, you can examine what called the invocation in the execution stack or you can jump to the source code of the method by right-clicking and selecting Show caller or Open source.
You can also see the time spent by hovering the cursor over any bar.
Open the Method Invocation Table to get a tabular view of the same method. Right click in the Method Invocation view and select Show Invocation Table. The Method Invocation Table opens.
Using both the Method Invocation view and the Method Invocation Table, identify the differences between method invocations, and the method invocations that take the longest time to execute.
Code coverage monitoring: User interface reference
Use these windows to detect UNTESTED lines and methods in your application.
The windows are part of the Profiling and Logging perspective, which can be used to analyze runtime problems.
The Coverage Statistics view for line and method coverage data
The Coverage Statistics view displays, in tabular format, coverage data for each package, class, and method in a profiling resource. Coverage data for each line of code can also be displayed, but only if the data was collected using a profiling set that included the Method and Line Code Coverage profiling type.
The Coverage Navigator view
The Coverage Navigator view displays, in tree format, an overview of line-level code coverage for each package, class, and method in a profiling resource, as well as a summary for the entire resource.
The Annotated Source view, source code with annotations display
In the Annotated Source view, the display of annotations for source code includes a copy of the source code marked with line-level coverage annotations.
The Annotated Source view, source data display
In the Annotated Source window, the display of coverage data for source code consists of pie charts that show line coverage statistics for classes and methods, and tables that provide coverage data for each line.
The Preferences pages for coverage data
Use the Annotated Source Preferences page and the related Graphical Styles and Source Styles Preferences pages to change the default appearance of the Annotated Source view.
Method Event and Pattern Editor dialog box
Use the Method Event and Pattern Editor dialog box to define events for flushing coverage data to the profiling resource.
Method and Line Code Coverage page, Edit Profiling Set dialog box
Use the Method and Line Code Coverage page to select options for the Method and Line Code Coverage profiling type.
Thread bottleneck detection: User interface reference
Use these windows to locate thread bottlenecks in your application.
The windows are part of the Profiling and Logging perspective, which can be used to analyze runtime problems.
The Thread View
The Thread View displays information for all the threads of a selected profiling resource. You can control the format and scope of the displays.
Use the Thread View as the primary view for detecting thread bottlenecks. It displays a record of the activity of each of the threads in your program, and helps you identify thread contentions and deadlocks.
A contention occurs when a thread is waiting for a resource that is not readily available; it slows the execution of your code, but can clear up over time.
A deadlock occurs when a thread is waiting for a resource that a second thread has locked, and the second thread is waiting for a resource that the first thread has locked. More than two threads can be involved in a deadlock. A deadlock never resolves itself. It often causes the whole application, or the part that is experiencing the deadlock, to halt.
The Call Stack View
The Call Stack View displays stack frames for all the threads of the selected profiling resources. The Call Stack View is designed to be used with the Thread View and the UML2 Object Interaction view.
The Thread View preferences page
Use this page to change the default appearance of the Thread View.
Thread Analysis page: Edit Profiling Set dialog box
Use the Thread Analysis page to select options for the Thread Analysis profiling type.
Collecting runtime data with user-defined probes
Probes are reusable Java code fragments that you write to collect detailed runtime information about a program's objects, instance variables, arguments, and exceptions. Probekit provides a framework on the Eclipse platform to help you create and use probes.
Probekit overview
Probekit is a framework on the Eclipse platform that you can use to write and use probes. Probes are Java code fragments that can be inserted into a program to provide information about the program as it runs.
Probes are defined by entries that you make in the Probekit editor. Fragments determine what the probe does.
Probe fragments can access data items that provide various kinds of information about the methods they are inserted into. For example:
Package, class, and method name
Method signature
this object
Arguments
Return value
Working with probes
Create, edit, and build probes using Probekit in the workbench. You can collect probe data when you profile Java applications by including probes as part of your profiling configuration, as well as in other ways that are provided for special situations. You can also export probes for use by others.
Probe definitions
The top-level Probe entry in the Probekit editor tree pane represents the definition of a single probe. Probes are contained in a Probekit source file with the extension .probe. A Probekit source file can contain more than one probe.
