The Collector gathers performance and coverage information about your running application and stores that information in a data file.

Chapter 2, Running the Collector gives complete details on using the Collector.

After your application completes its execution cycle, you can use the Analyzer to view and interpret the performance or coverage information that has been gathered. The Analyzer main window is shown in Figure 1.3, “Analyzer Main Window”.

The Analyzer also provides several navigational functions so you can easily traverse your application's structure to locate hotspots, places in your application that have generated the most collection activity.

Chapter 3, Running the Analyzer explains how to invoke and use the Analyzer.

Using the DECwindows interface, after the Collector main window is displayed on your screen, by default the Collector automatically opens a data file. If a data file with the same name as your application already exists, the Collector opens that data file and appends new collection information to it. If no such data file already exists, the Collector creates one, and assigns it the name of the application with a file type of .PCA.

Although it is not required in most cases, you should keep all the performance and coverage information for an application in one data file.

Figure 2.1, “Opening a Data File” shows the File menu and the New Datafile dialog box.

This section describes how to choose a query using the DECwindows interface. A query is a specific question appearing in the Collector main window that corresponds to a specific type of information to collect. For example, the query that corresponds to elapsed time information is “Where is elapsed time spent?” A query category is a grouping of associated queries. For example, the Process Execution query category contains three queries that pertain to the basic run-time characteristics of your application: where the most elapsed and process time is spent, and what routines are executed the most.

Use the Options menu to get access to the customization functions, as shown in Figure 2.3, “Collector Options Menu”. This pull-down menu's Vector Range option is available only on OpenVMS VAX systems.

2.2.3.1. Customizing the Sampling Interval for Elapsed or Process Time

When the Collector gathers information on where your application is spending the most time, it uses an algorithm that involves noting the currently executing program address at regular intervals of time. By default, the interval is 10 milliseconds.

To customize the sampling interval for elapsed or process time, do the following:

1. Choose the Interval... menu item from the Customize menu.

2. In the Set Sampling Rate dialog box, click on the menu next to either the Elapsed Time or Process Time sampling rate labels.

3. Choose a sampling rate in the displayed menu.

Figure 2.4, “Set Sampling Rate Dialog Box” shows the Set Sampling Rate dialog box.

2.2.3.2. Specifying Collection Elements

You can focus a collection on specific modules, specific routines, or all lines of your application when you are collecting information such as the following:

• Counting information

• Coverage information

Focusing collection activity on specific program elements in your application is useful once you have narrowed down the locations of your performance bottlenecks, or if you have a particularly large application.

Figure 2.5, “Specific Elements List Box” shows the Specific Elements list box, which is displayed when you choose Specific Elements... in the Counting Range, Coverage Range, or Vector Range dialog boxes. To specify a module or routine in the Specific Elements list box, click on the module or routine name, then click on OK.

OpenVMS Alpha systems offer an additional “Where are unaligned data exceptions?” query. By comparing where your application spends the most elapsed and process time, you can determine where your application spends idle time.

Examining execution counts information helps you to identify inefficient algorithms, or excessive calls to other routines or system services in your application.

Designing tests that execute all the code paths of your application is important in determining how your application performs under the circumstances for which the application is intended.

Collecting coverage information is useful for determining if the tests you are using during your collection runs are adequately covering all your application's code paths. In addition, collecting coverage information can tell you how to change your tests to give acceptable code path coverage if the tests initially do not adequately exercise all code paths.

By determining the basic, run-time calling relationships among the routines in your application, especially determining which routines are executed most, you can determine if your application is calling routines efficiently.

By comparing I/O usage information with process execution and executions counts information, you can determine if your application is using I/O services excessively or inefficiently.

By comparing system service usage information with process execution and executions counts information, you can determine if your application is using system services excessively or inefficiently.

Page fault information is useful in determining how your application is using system resources in general. For example, page fault information can tell you why your application is consuming a lot of time in system space.

If you have an application running on a computer with a vector processor, you can use the information from the Vector Usage category to determine how efficiently your application is using the vector processor. In addition, you can determine how you have split the processing of your application between the scalar and vector processors in your computer.

Figure 3.3, “Sample Histogram”, Figure 3.5, “Sample Annotated Source Listing”, and Figure 3.5, “Sample Annotated Source Listing” show, respectively, a sample histogram, call tree, and annotated source listing.

You can increase the granularity of information only from views of modules or routines; you can decrease the granularity of information only from views of lines or routines.

Some applications appear to spend a lot of time in system space, as the histogram in Figure 4.2, “Sample 2 of Elapsed Time Histogram” shows.

When you see elapsed time information displayed in a histogram, you can get abroad measure of what routines are consuming the most elapsed time. You can increase the granularity of the elapsed time information in the Analyzer by displaying an annotated source listing.

Although the current chart can be a histogram, you can view elapsed time information in an annotated source listing. Use the DECwindows interface by clicking on the right arrow view button.

The Analyzer displays a histogram showing the total test coverage among all the routines in your application. Figure 6.1, “Test Coverage Histogram” is an example test coverage histogram of the application PCA$PRIMES.

In Figure 6.1, “Test Coverage Histogram”, the bars and percentage figures for each line represent the percentage of coverage points for that line, with respect to the total number of lines covered.

For a breakdown of test coverage by line, click on the right arrow view button. Figure 6.2, “Test Coverage Information By Line” is an example of an annotated source listing showing which lines were covered by tests.

In Figure 6.2, “Test Coverage Information By Line”, the Analyzer displays a nonzero percentage figure to the left of lines that were covered, and a zero percentage figure next to the lines that were not covered.

The Analyzer displays a histogram showing only those routines that received no test coverage at all. Figure 6.3, “Test Noncoverage” is an example histogram that shows routines that were completely not covered by tests in the application PCA$PRIMES.

For a breakdown of test noncoverage by line in a particular routine, click onthat routine in the display pane and click on the right arrow View button. To see the first occurrence of a noncovered line, click on Next Hotspot in the Navigate menu. Figure 6.4, “Test Noncoverage Information By Line” is an example of an annotated source listing that shows which lines were not covered by tests. The display points to the first occurrence of a noncovered line.

Choosing the query “Where are system services used?” shows you where system services are used in your application. You can see that information by routine or by line in a histogram or table. Figure 7.1, “Histogram Showing Where System Services Are Used” is a histogram showing by routine where system services were used in the application PCA$PRIMES.

In Figure 7.1, “Histogram Showing Where System Services Are Used”, nearly all the system services are used in the routine OUTPUT_TO_DATAFILE.

To get more information on system services usage, click on the right arrow View button. Figure 7.2, “Annotated Source Showing Where System Services Are Used” shows an annotated source listing of system service usage for each line in the application PCA$PRIMES.

Choosing the query “What system services are used?” causes the Analyzer to display a histogram showing what system services are being used in your application, as shown in Figure 7.3, “Histogram Showing What System Services Are Used”.

When you choose the query “Where is I/O being done?” the Analyzer displays a histogram showing the routines that are making the most use of I/O operations. Figure 7.4, “Histogram Showing Where I/O Operations Are Being Performed” shows where I/O operations are being performed in the application PCA$PRIMES.

Figure 7.4, “Histogram Showing Where I/O Operations Are Being Performed” shows that the routine OUTPUT_TO_DATAFILE is performing 93.5 percent of all the I/O operations in PCA$PRIMES. If your application has a routine in which a large percentage of I/O operations are being performed, get more information on that routine.

If your application performs I/O operations throughout numerous locations and in several different routines, consider centralizing the location of the I/O operations. Compare elapsed time, process time, and execution count information with the I/O information for that routine. If a routine is consuming idle time in addition to using a lot of I/O services, find out what I/O services are being used.

When you choose the query “What I/O system services are being used?” the Analyzer displays a histogram showing which I/O operations are being used most in your application. Figure 7.5, “Histogram Showing What I/O Operations Are Being Performed” shows the I/O operations being used the most in the application PCA$PRIMES.

In Figure 7.5, “Histogram Showing What I/O Operations Are Being Performed”, SYS$PUT represents 92.4percent of all I/O services used in PCA$PRIMES. If your application has a high usage of one I/O service, check to see how it is being used. In this example, check to see where you are sending output to a file and see if that location is generating a lot of idle time. If so, you might look at ways to make that algorithm more efficient, or optimize use of the I/O output statement.

To get this information, click on the appropriate query in the Analyzer query panel.

When you choose the query “Where are the page faults occurring?”the Analyzer displays a histogram showing the routines that generates the most page faults. Figure 7.6, “Histogram Showing Where Page Faults Are Occurring” shows a sample histogram.

Figure 7.6, “Histogram Showing Where Page Faults Are Occurring” shows that more than 25 percent of the page faults are occurring in system space. This might indicate that the page faults are caused by system service or I/O calls. To get more information, choose the query “What are the addresses causing page faults?”

When you query “What are the addresses causing page faults?”, the Analyzer displays the addresses of the instructions that are causing the page faults.

Figure 7.7, “Addresses of Instructions Causing Page Faults” shows sample addresses of instructions that cause page faults.

When you choose the query “What tasks are performing context switching?”,the Analyzer displays a histogram showing the percentage of each task that performs context switching.

Figure 7.8, “Histogram Showing What Tasks Are Performing Context Switching” shows that Run 1 and Run 3 represent context switching 17.6 percent of Task 1. Similarly, Run 3 represents the same percent of context switching of Task 3 and Task 4. To get more information, choose the query “What are the Ada tasking names used?”

When you query “What are the Ada tasking names used?”, the Analyzer displays the percentage of each task name used, as shown in Figure 7.9, “Histogram Showing What Ada Tasking Names Are Used”.

Figure 7.9, “Histogram Showing What Ada Tasking Names Are Used” shows that Run 1 and Run 3 represent 17.6 percent of Task 1. Similarly, Run 3 represents the same percent of Task 3 and Task 4. For more information, query “What are the Ada tasking types used?”

When you query “What are the Ada tasking types used?”, the Analyzer displays the percentage of each task type used, as shown in Figure 7.10, “Histogram Showing What Ada Tasking Types Are Used”.

Figure 7.10, “Histogram Showing What Ada Tasking Types Are Used” shows that MAIN$TASK represents 35.1 percent and that ADA$START_UP represents only 1.4 percent of all Ada tasking used in DISCCHAR. To get more information, choose the query “What are the Ada task priorities used?”

When you query “What are the Ada task priorities used?”, the Analyzer displays the percentage of task priorities used, as shown in Figure 7.11, “Histogram Showing What Ada Task Priorities Are Used”.

Figure 7.11, “Histogram Showing What Ada Task Priorities Are Used” shows that task priority 7 represents 54.1 percent, task priority 5 represents 23.0 percent, task priority 10 represents 21.6 percent, and task priority 0 represents only 1.4 percent of all Ada tasking used in DISCCHAR.