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.

Note: The overhead for collecting line-level coverage data can distort the performance data that you collect. If you do not get results similar to those described here, use one profiling run to collect data for performance, and another profiling run to collect data for coverage. Keep this in mind when you profile your own programs.

To find bottlenecks:

  1. In the Profiling Monitor, right-click the "Execution Time Analysis" profiling resource, and then click 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 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:
    1. Right-click the "Execution Time Analysis" profiling resource and select Open With > Execution Statistics.
    2. Execution Statistics view

    3. In the Execution Statistics view, click the Method Level Information button ().

      Execution Statistics view displaying method level information

    4. 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.

      Execution Statistics view, sorted by base time

You have now verified that the quick method consumes more time than 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.

Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.