Exercise 1.3: Identifying a performance bottleneck

Before you begin, you must complete Exercise 1.2 Collecting performance and coverage data.

Performance bottlenecks are areas within the code that slow down or halt execution. In this procedure, you use Performance Call Graph View to identify a bottleneck within the sort program.

To find bottlenecks:

  1. In the Profiling Monitor, right-click the Profiling resource, and then select Open With > Performance Call Graph.

    Screenshot of the performance call graph. The information that it shows is described in the accompanying text.

    The Performance Call Graph view, by default, displays the following information:

    Tip: Right-click a node to display a menu that allows you to focus the display on the node and its descendants (the Subtree), or to manipulate the display in other ways. These menu commands allow you to simplify the mass of data that you collect for even a small application.

    Popup menu showing the Filter, Subtree, and Expand/Collapse commands that you can use to focus the call graph.

  2. Note that in the Highlight field, located above the graph, Max Path to Root is selected.

    Max Path to Root highlighting shows you the single most time-consuming call path in the current run of the application. Specifically, it changes the call graph display in the following ways:

  3. Note that there is also a bsort method in the call graph, representing the bubble sort algorithm. It's clear from the thickness of the lines that bsort performed better than qsort in this run.

Getting additional performance information

Both the Performance Call Graph view and other views in the platform provide additional details about your application's performance.

You can get additional performance data in the following ways:

  1. To learn more about how Sort.quick performed, pause your cursor over the Sort.quick node. A tool-tip appears with statistics for the method. Note that the method makes a many calls.

  2. To get a detailed graphical display of the data for the method, double-click the node. The Method Detail view opens.

    Method Detail view with data for the Sort.quick method

  3. In the Method Detail view, look at the Callers pane. Note that the method is called by Sort.Qsort once, but that it calls itself several thousand times. This in itself is not suspicious; a quick sort is typically heavily recursive. However, the relatively large amount of time for the calls is suspicious.
  4. To examine a sortable list of all methods, right-click the profiling resource and select Open With > Method Statistics.

    Click the column header Base Time to sort the methods according to the amount of time spent within each method during the current run. You can see that quick is considerably slower than the bubble sort method bsort.

You have now verified that the quick method consumes more time that was expected. You have also seen how to get performance information from the Performance Call Graph and Method Detail views. This information will be important when you inspect the code and figure out where you need to make modifications.

Before inspecting the code, however, we should also find out if there were any methods in the code that were not executed. This check will give us a better understanding of the scope of the application, and will also indicate whether there are any alternative paths this program might contain.

You are ready to begin Exercise 1.4: Checking code coverage, to determine if there are any unexecuted methods and alternative paths.

Terms of use | Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.