The following factors determine whether a data view is displayed in the navigation bar when you open an experiment:
The type of data in the experiment determines what data views should be displayed. For example, if an experiment contains OpenMP data, the views for OpenMP are automatically opened to display the data.
Configuration files which are read when you start Performance Analyzer specify the default data views to display.
You can use the Views menu or button to open the Settings dialog box (see Views Settings) to select the views that you want to display in the current Performance Analyzer session.
Most views have a context menu that opens when you by right-click on an item in the view. You can use the context menu to add filters or to perform other activities related to that data view. When you apply filters in one view, the data is filtered in all the views that can be filtered.
The navigation bar shows the following:
When you start Performance Analyzer without specifying on the command line which experiment to open, the first page you see if the Welcome page. The Welcome page makes it easy to start profiling an application, view recent experiments, compare experiments, and view documentation. After you open an experiment, you can still select the Welcome page from the navigation panel at any time during a Performance Analyzer session.
The following figure shows the Welcome page.
Figure 3 Performance Analyzer Welcome Page
When you open an experiment Performance Analyzer displays the Overview, which shows performance metrics for the loaded experiments and can give you a quick idea of where the metrics are high. Use the Overview to select the metrics you want to explore in other views. Press F1 while viewing the Overview for detailed information about the Overview.
The following figure shows the Performance Analyzer window with the Overview displayed.
Figure 4 Performance Analyzer's Overview Screen
As you select metrics, the Metrics Preview panel at the bottom of the window show how the metrics will look in the data views. You can specify which metrics you want to see in the data views, by using a selection button or specifically selecting which metrics you are interested in. For more information, see the Overview Screen topic in the help.
The Functions view shows a list of the target program's functions and their metrics, which are derived from the data collected in the experiment. Metrics can be either exclusive or inclusive. Exclusive metrics represent usage only by the function itself. Inclusive metrics represent usage by the function and all the functions it called. For more detailed information about metrics, see Function-Level Metrics: Exclusive, Inclusive, Attributed, and Static.
The list of available metrics for each kind of data collected is given in the collect(1) man page and the help, and in Performance Data.
Time metrics are shown as seconds, presented to millisecond precision. Percentages are shown to a precision of 0.01%. If a metric value is precisely zero, its time and percentage is shown as “0.” If the value is not exactly zero but is smaller than the precision, its value is shown as “0.000” and its percentage as “0.00”. Because of rounding, percentages may not sum to exactly 100%. Count metrics are shown as an integer count.
The metrics initially shown are based on the data collected. If more than one type of data has been collected, the default metrics for each type are shown. You can select which metrics to display in the Overview page. See Overview Screen for more information.
To search for a function, use the Find tool in the toolbar.
To view the source code for a function, double-click on it to open the Source view at the correct line in the source code.
To select a single function, click that function and see more information about it in the Selection Details window on the right side.
To select several functions that are displayed contiguously in the view, select the first function of the group, then Shift-click on the last function of the group.
To select several functions that are not displayed contiguously in the view, select the first function of the group, then select the additional functions by Control-clicking on each function.
The Timeline view shows a chart of the events and the sample points recorded as a function of time. Data is displayed in horizontal bars. By default, for each experiment there is one bar for CPU Utilization Samples at the top and a set of profiling data bars for each thread. The data shown for each thread is determined by the data you collected when you profiled your application.
The Timeline view enables you to do the following with your program:
Identify phases of program activity
Highlight functions and methods, using custom coloring
Zoom in by time and vertical axes to see details
View complete event information on the Selection Details panel
Filter global data by time range, threads, and CPUs
You might see the following data bars:
When an experiment includes sample data, the top bar displayed is CPU Utilization Samples. Data in a sample point represents CPU time spent between that point and the previous point. Samples data include microstate information, which is available on Oracle Solaris systems.
Oracle Solaris operating systems use a technology called microstate accounting to gather statistics about the execution state for every event. The timing metrics for events shown by Performance Analyzer correspond to the relative amount of time spent in each state. CPU Utilization Samples displays a summary of the timing metrics for all the threads in the experiment. Click a sample to display the timing metrics for that sample in Selection Details panel on the right. You can display timing metrics for individual events in the timeline by displaying event states.
The data bars for clock profiling, hardware counter profiling, and tracing data show an event marker for each event recorded. The event markers consist of a color-coded representation of the call stack that was recorded with the event.
Click an event marker to see information about the event in the Selection Details panel and the call stack functions in the Call Stack panel. Double-click functions in the Call Stack panel to go to the Source view and see the source for the function along with metrics.
For some kinds of data, events can overlap and not be visible. Whenever two or more events would appear at exactly the same position, only one can be drawn; if there are two or more events within one or two pixels, all are drawn, although they may not be visually distinguishable. In either case, a small gray tick mark is displayed below the event indicating the boundaries of that event. You can zoom in to see the events. You can use the left and right arrow keys to move the event selection in either direction and make hidden events become visible. You can see more information about events by displaying event density.
Heap Size data is available only if the heaptrace collection option is enabled. Heap Size consists of two graphs. Net Bytes Allocated tracks the allocated bytes minus the free byes. Net Bytes Leaked shoes the accumulation of allocated bytes that are never freed.
For clock profiling data recorded on Oracle Solaris, the event state chart shows Oracle Solaris microstates. The color coding for event states is the same as for the CPU Utilization Samples bar.
Event states are displayed by default. You can hide them by clicking the Timeline Settings button Timeline settings icon in the Timeline toolbar and deselecting Event States in the Timeline area of the Settings dialog box.
To show event density, click the Timeline Settings button Timeline settings icon in the timeline toolbar and select Event Density in the Timeline area of the Settings dialog box.
Event density is then displayed immediately below the timeline data bar for each data type. Event density displays the count of events that occurred in each horizontal time slice. The scale of the vertical axis of the line chart is 0 to the highest event count for that specific data bar in the visible time range.
When the Timeline's zoom setting is such that there are many events in each visible time slice, event density can be used to identify periods of high event frequency. To explore such a period, you can zoom in. Then you can right-click and select a context filter to include only data from the visible time range, and analyze that data from that specific period using the other Performance Analyzer data views.
High metrics are highlighted in yellow to indicate source lines that are hot areas of resource usage. An orange navigation marker is also shown in a margin next to the scrollbar on the right for each hot source line. Non-zero metrics that are below the hot threshold are not highlighted, but are flagged with grey navigation markers.
To quickly navigate to source lines with metrics, click the yellow markers in the right margin to jump to the lines with metrics. To jump to the next line with metrics, right-click the metrics themselves and select an option such as Next Hot Line or Next Non-Zero Metric Line.
The Source view shows the full paths to the source file and the corresponding object file, and the name of the load object in the column heading for the source code. In the rare case where the same source file is used to compile more than one object file, the Source view shows the performance data for the object file containing the selected function.
If Performance Analyzer cannot find a source file, you can click the Resolve button in the Source view to browse to the source file or type the path to the source or browse to it and then the source code is displayed from the new location. Optionally, you can select Archive Source Files Inside Experiment. This will copy the source files into the experiment. For more information about this button, see the Resolve Source File topic in the Help menu.
See How the Tools Find Source Code for a description of the process used to find an experiment's source code.
When you double-click a function in the Functions view and the Source view is opened, the source file displayed is the default source context for that function. The default source context of a function is the file containing the function's first instruction, which for C code is the function's opening brace. Immediately following the first instruction, the annotated source file adds an index line for the function. The source window displays index lines as text in red italics within angle brackets in the form:
A function might have an alternate source context, which is another file that contains instructions attributed to the function. Such instructions might come from include files or from other functions inlined into the selected function. If there are any alternate source contexts, the beginning of the default source context includes a list of extended index lines that indicate where the alternate source contexts are located.
<Function: f, instructions from source file src.h>
Double-click an index line that refers to another source context opens the file containing that source context at the location associated with the indexed function.
To aid navigation, alternate source contexts also start with a list of index lines that refer back to functions defined in the default source context and other alternate source contexts.
The source code is interleaved with any compiler commentary that has been selected for display. You can set the classes of commentary shown in the Settings dialog box. The default classes can be set in a .er.rc defaults file.
The metrics displayed in the Source view can be changed or reorganized. See the Help menu for details.
For detailed information about the content of the Source view, see Performance Analyzer Source View Layout.
The ame Graph view shows the same data as the Call Tree view, but in a graphical format. Call stacks climb vertically while the width of each frame is proportional to the selected inclusive metric. As a result, wider frames indicate hotter call paths. Frames are colored according to their function names. See the following screenshot as an example.
Figure 5 Flame Graph View in Performance Analyzer
While both the Call Tree and the me Graph can show the full tree starting from <Total>, the ame Graph can zoom in on a partial tree from a selected function. To see when a call path was sampled, filter by the desired call path, then open the Timeline view.
For more information on the ame Graph view, see the Help topic in Performance Analyzer.
The Call Tree view displays a dynamic call graph of the program as a tree, with each function call shown as a node that you can expand and collapse. An expanded function node shows all the function calls made by the function, plus performance metrics for those function calls.
When you select a node, the Selection Details window displays metrics for the function call and its callees. The percentages given for attributed metrics are the percentages of the total program metrics. The default root of the tree is <Total>, which is not a function but represents 100% of the performance metrics of all the functions of the program.
Use the Call Tree view to see details of specific call traces and analyze which traces have the greatest performance impact. You can navigate through the structure of your program, searching for high metric values.
To set a predefined filter for the selected branch or selected functions, right-click in the Call Tree view to open a context menu. By filtering in this way you can screen out data in all the Analyzer views for areas you are not interested in.
The Callers-Callees view shows the calling relationships between the functions in your code, along with performance metrics. The Callers-Callees view enables you to examine metrics for code branches in detail by building call stack fragments one call at a time.
The view shows three separate panels: the Callers panel at the top, the Stack Fragment panel in the center, and the Callees panel at the bottom. When you first open the Callers-Callees view, the function in the Stack Fragment panel is the function that you selected in one of the other Analyzer views, such as the Function view or Source view. The Callers panel lists functions that call the function in the Stack Fragment panel, and the Callees panel lists functions that are called by the function in the Stack Fragment panel.
To add a call to the stack fragment, double-click a function in the Callers pane or Callees pane, or select a function and click the Add button.
To remove a function call, double-click the function at the top or bottom of the call stack fragment, or select the top or bottom function and click Remove.
To set a function as the head (top), center, or tail (bottom) of the call stack fragment, select the function and click Set Head, Set Center, or Set Tail. This new ordering causes other functions currently in the call stack fragment to move to the Callers area or Callees area to their appropriate location in relation to the new location of the selected function in the stack fragment.
Use the Back and Forward buttons located above the Stack Fragment panel to go through the history of your changes to the call stack fragment.
As you add and remove functions in the stack fragment, the metrics are computed for the entire fragment and displayed next to the last function in the fragment.
You can select a function in any panel of the Callers-Callees view and then right-click to open a context menu and select filters. The data is filtered according to your selection in this view and all the Analyzer data views. See the online help for details about using context filters.
For the call stack fragment in the Stack Fragment panel, the attributed metric represents the exclusive metric for that call stack fragment.
For the callees, the attributed metric represents the portion of the callee's metric that is attributable to calls from the call stack fragment. The sum of attributed metrics for the callees and the call stack fragment should add up to the metric for the call stack fragment.
For the callers, the attributed metrics represent the portion of the call stack fragment's metric that is attributable to calls from the callers. The sum of the attributed metrics for all callers should also add up to the metric for the call stack fragment.
For more information about metrics, see Function-Level Metrics: Exclusive, Inclusive, Attributed, and Static.
Each Index Objects view shows the metric values from data attributed to various index objects, such as Threads, CPUs, and Seconds. Inclusive and Exclusive metrics are not shown, because Index objects are not hierarchical. Only a single metric of each type is shown.
Several Index Objects views are predefined: Threads, CPUs, Samples, Seconds, Processes, and Experiment IDs. These views are described separately below.
You can also define a custom index object. Click on the Add Custom View button in the Settings dialog box, the set the values for the object in the Add Index Objects dialog box.
The Threads view shows a list of threads and their metrics. The threads are represented by a Process and Thread pair and show the Total CPU time by default. Other metrics might also be displayed by default if the metrics are present in the loaded experiments. The Threads view is not displayed by default. You can select it from the Views menu.
You can use the filter button to filter the data shown in this and Performance Analyzer views.
The CPUs view shows a list of CPUs that processed the target application's run, along with their metrics. The CPUs are represented by a CPU number and show the Total CPU time by default. Other metrics might also be displayed by default if the metrics are present in the loaded experiments. If the CPUs view is not visible you can select it from the Views menu.
You can use the filter button to filter the data shown in this and Performance Analyzer views.
The Samples view shows a list of sample points and their metrics, which reflect the microstates recorded at each sample point in the loaded experiments. The Samples are represented by Sample numbers and show the Total CPU time by default. Other metrics might also be displayed if you selected them in the Overview panel or in the Settings dialog box. If the Samples view is not visible you can select it from the Views menu.
You can use the filter button to filter the data shown in this and Performance Analyzer views.
For more information on sample points, see the Performance Analyzer Help topic Sample Points.
The Seconds view shows each second of the program run that was captured in the experiment, along with metrics collected in that second. The Seconds view differs from the Samples view in that it shows periodic samples that occur every second beginning at 0 and the interval cannot be changed. The Seconds view lists the seconds of execution with the Total CPU time by default. Other metrics might also be displayed if the metrics are present in the loaded experiments. If you have selected other metrics in the Overview or by using the Settings dialog, those metrics are also displayed.
You can use the filter button to filter the data shown in this and Performance Analyzer views.
The Processes view shows a list of processes that were created by your application, along with their metrics. The Processes are represented by process ID (PID) numbers and show the Total CPU time metric by default. Other metrics might also be displayed if the metrics are present in the loaded experiments. If you have selected other metrics in the Overview or by using the Settings dialog, those metrics are also displayed.
The Processes view enables you find the processes that used the most resources. If there is a particular set of processes that you want to isolate and explore using other views, you can filter out other processes using the filters available in the context menu.
The Experiment IDs view shows a list of processes that were created by your application, along with their metrics. The Experiment IDs are represented by process ID (PID) numbers and show the Total CPU time metric by default. Other metrics might also be displayed if the metrics are present in the loaded experiments. If you have selected other metrics in the Overview or by using the Settings dialog, those metrics are also displayed. The metrics values reflect the microstates recorded at each sample point in the loaded experiments. The values reflect the value or percentage of the metrics that were recorded in each of the loaded experiments.
Each MemoryObjects view shows the metric values for dataspace metrics attributed to the various memory objects such as pages. If one or more of the loaded experiments contains a dataspace profile, you can select the memory objects for which you want to display views in the Views tab of the Settings dialog box. Any number of MemoryObjects views can be displayed.
Various MemoryObjects views are predefined. Memory objects are predefined for virtual and physical pages with names such as Vpage_8K, Ppage_8K, Vpage_64K, and so on. You can also define a custom memory object. Click the Add Custom Object button in the Settings dialog box, then set the values for the object in the Add Memory Objects dialog box.
The DataLayout view shows the annotated data object layouts for all program data objects with data-derived metric data. The view is applicable only to experiments that include dataspace profiling, which is an extension of hardware counter overflow profiling. See Dataspace Profiling and Memoryspace Profiling for more information.
The layouts appear in the view sorted by the data sort metrics values for the structure as a whole. The view shows each aggregate data object with the total metrics attributed to it, followed by all of its elements in offset order. Each element, in turn, has its own metrics and an indicator of its size and location in 32–byte blocks.
To display the DataLayout view, select it in the Views tab of the Settings dialog box (see Views Settings). As with the DataObjects view, you can make the DataLayout view visible only if one or more of the loaded experiments contains a dataspace profile.
To select a single data object, click that object.
To select several objects that are displayed contiguously in the view, select the first object, then press the Shift key while clicking the last object.
To select several objects that are not displayed contiguously in the view, select the first object, then select the additional objects by pressing the Ctrl key while clicking each object.
The DataObjects view shows the list of data objects with their metrics. The view applies only to experiments that include dataspace profiling, which is an extension of hardware counter overflow profiling. See Dataspace Profiling and Memoryspace Profiling for more information.
You display the view by selecting it in the Views tab of the Settings dialog box (see Views Settings). You can make the DataObjects view visible only if one or more of the loaded experiments contains a dataspace profile.
To select a single data object, click that object.
To select several objects that are displayed contiguously in the view, select the first object, then press Shift while clicking the last object.
To select several objects that are not displayed contiguously in the view, select the first object, then select the additional objects by pressing Ctrl while clicking each object.
Use the I/O view to identify the I/O patterns in your application and pinpoint the I/O bottlenecks that impact its performance. The I/O view is available if you profiled your application for I/O tracing data.
You can aggregate the I/O data according to one of the following options:
Shows a table of the files accessed by the program. Each row represents a file. The metrics for one row represent the aggregated I/O statistics for all accesses of the file.
Shows a table of file descriptors for files accessed by the program. Each row represents a single instance of a file being opened. If the same file is opened multiple times the table contains multiple rows for the same file. The metrics for one row apply to a single instance of the file opening.
Shows a table of call stacks listed with arbitrary stack numbers. Click a stack to see the function calls in the stack displayed in the Call Stack panel. The metrics apply to the selected call stack.
The Heap view shows a list of call stacks that have memory allocation metrics that indicate possible memory leaks. The call stacks are identified by arbitrary stack numbers. One call stack is labeled to indicate peak memory usage.
Click a call stack to display the metrics details in the Selection Details panel and display the call stack's function calls in the Call Stack panel. You can double-click a function in the Call Stack panel to see the source. You can also set filters to filter out the selected call stacks or to filter out the unselected call stacks. You can select the Heap view in the Views tab of the Settings dialog box only if one or more of the loaded experiments contains heap trace data. The bottom panel of the Heap view shows detailed data for the <Total> pseudo function which represents the full target application.
The Data Size view is available for experiments that contain data that has a size element such as a number of bytes. Experiments that include heap tracing, I/O tracing, or MPI tracing have a Data Size view.
The Data Size view organizes the data into ranges of data sizes and calculates the metrics for the events whose data falls into a given range. Data without a size element is attributed to data size 0.
You can use the Data Size view to filter the data. For example, in an experiment that contains heap tracing data, you could select a size range line that has high metrics for Bytes Leaked and add the filter Include only events with selected items. When you go to other data views, the data is filtered to show only events that produced memory leaks of that size range you selected.
The Duration view is available for experiments that contain data that has a duration. Experiments that include I/O tracing data, MPI tracing, heap tracing, and synchronization tracing data have a Duration view.
The Duration view organizes the data into ranges of duration time and calculates the metrics for the events whose data falls into each range of duration time. The duration of the function call is recorded for I/O tracing, MPI tracing, and synchronization tracing. For heap tracing, the duration is the time between allocation and freeing of memory. Data without a duration element is attributed to duration 0.
You can use the Duration view to filter the data. For example, in an experiment that contains heap tracing data, you could select a duration range line that has high metrics for Bytes Allocated and add the filter Include only events with selected items. When you go to other data views, the data is filtered to show only events whose duration matched the range you selected and might reveal memory allocations that are longer duration than expected.
The OpenMP Parallel Region view is applicable only to experiments that were recorded with the OpenMP 3.0 collector, for programs that use OpenMP tasks compiled with Oracle Developer Studio compilers. See Limitations on OpenMP Profiling for more information.
The view lists all parallel areas encountered during the program's execution along with metric values computed from the same profiling data. Exclusive metrics are computed for the current parallel region. Inclusive metrics reflect nested parallelism. They are attributed to the current parallel region, and the parent parallel region from which it was created. The attributions go further on recursively up to the topmost Implicit OpenMP Parallel Region, representing the serial execution of the program (outside any parallel region). If there are no nested parallel regions in a program, the exclusive and inclusive metrics have the same values.
If a function containing a parallel region is called many times, all instances of the parallel region will be aggregated together and presented as one line item in the corresponding view.
The view is useful for navigation. You can select an item of interest, such as the parallel region with the highest OpenMP Wait time, and analyze its source or select a context filter to include only the data related to the selected item. You can then analyze how the data is represented by other program objects using other views: Functions, Timeline, Threads, and so on.
The OpenMP Task view shows the list of OpenMP tasks with their metrics. The options in this view are applicable only to experiments that were recorded with the OpenMP 3.0 collector, for programs that use OpenMP tasks compiled with Oracle Developer Studio compilers. See Limitations on OpenMP Profiling for more information.
The view lists tasks encountered during the program's execution, along with metric values computed from the profiling data. Exclusive metrics apply to the current task only. Inclusive metrics include metrics for OpenMP tasks plus those of their child tasks, with their parent-child relationship established at the task creation time. The OpenMP Task from Implicit Parallel Region represents the serial execution of the program.
If a function containing a task is called many times, all instances of the parallel region will be aggregated together and presented as one line item in the corresponding view.
The view is useful for navigation. You can select an item of interest, such as the task with the highest OpenMP Wait time, analyze its source by clicking the Source view. You can also right-click to select a context filter to include only the data related to the selected item, You can then analyze how it's represented by other program objects using other views: Functions, Timeline, Threads, and so on.
Source lines are labeled with the function from which they came and the line number and source file name. If no line-number information is available for a function, or if the source file for the function is not known, all of the function’s program counters (PCs) appear aggregated into a single entry for the function in the lines display. PCs from functions that are from load-objects whose functions are hidden appear aggregated as a single entry for the load-object in the lines display. Selecting a line in the Lines view shows all the metrics for a given line in the Selection Details window. Selecting the Source or Disassembly view after selecting a line from the Lines view positions the display at the appropriate line.
The PCs view lists program counters (PCs) and their metrics. PCs are labeled with the function from which they came and the offset within that function. PCs from functions that are from load-objects whose functions are hidden appear aggregated as a single entry for the load-object in the PCs display. Selecting a line in the PCs view shows all the metrics for that PC in the Summary tab . Selecting the Source view or Disassembly view after selecting a line from the PCs view positions the display at the appropriate line.
See the section Call Stacks and Program Execution for more information about PCs.
The Disassembly view shows a disassembly listing of the object file containing the selected function, annotated with performance metrics for each instruction. You might need to select Machine from the View Mode list in the toolbar to see the disassembly listing.
Interleaved within the disassembly listing is the source code, if available, and any compiler commentary chosen for display. The algorithm for finding the source file in the Disassembly view is the same as the algorithm used in the Source view.
Just as with the Source view, index lines are displayed in Disassembly view. But unlike with the Source view, index lines for alternate source contexts cannot be used directly for navigation purposes. Also, index lines for alternate source contexts are displayed at the start of where the #included or inlined code is inserted, rather than just being listed at the beginning of the Disassembly view.
Code that is #included or inlined from other files shows as raw disassembly instructions without interleaving the source code. However, placing the cursor on one of these instructions and selecting the Source view opens the source file containing the #included or inlined code. Selecting the Disassembly view with this file displayed opens the Disassembly view in the new context, thus displaying the disassembly code with interleaved source code.
You can set the classes of commentary that are displayed in the Settings dialog box. The default classes can be set in a .er.rc defaults file by clicking the Save button in the dialog box.
Performance Analyzer highlights hot lines, which are lines with metrics that are equal to or exceed a metric-specific threshold, to make it easier to find the important lines. You can set the threshold in the Settings dialog box.
As with the Source view, yellow navigation markers are shown in a margin next to the scrollbar on the right for each source line with metrics. Non-zero metrics that are below the hot threshold are not highlighted but are flagged with yellow navigation markers. To quickly navigate to source lines with metrics, you can click the yellow markers in the right margin to jump to the lines with metrics. You can also right-click the metrics themselves and select an option such as Next Hot Line or Next Non-Zero Metric Line to jump to the next line with metrics.
For detailed information about the content of the Disassembly view, see Annotated Disassembly Code.
The Source/Disassembly view shows the annotated source in an upper pane, and the annotated disassembly in a lower pane. The panes are coordinated so that when you select lines in one pane the related lines in the other pane are also selected. The view is not visible by default.
The Races view shows a list of all the data races detected in a data-race experiment. You can click a data race to see details about it in the Race Detail window on the right panel. For more information, see Oracle Developer Studio 12.6: Thread Analyzer User’s Guide.
The Deadlocks view shows a list of all the deadlocks detected in a deadlock experiment. Click a deadlock to see details about it in the Deadlock Details window in the right panel. For more information, press F1 to view the help and see Oracle Developer Studio 12.6: Thread Analyzer User’s Guide.
The Dual-Source view shows the two source contexts involved in the selected data race or deadlock. The view is shown only if data-race-detection or deadlock experiments are loaded. See Oracle Developer Studio 12.6: Thread Analyzer User’s Guide for more information.
The Statistics view shows totals for various system statistics summed over the selected experiments and samples. The totals are followed by the statistics for the selected samples of each experiment. For information on the statistics presented, see the getrusage(3C) and proc (4) man pages.
The Experiments view is divided into two panels. The top panel contains a tree that includes nodes for the load objects in all the loaded experiments, and for each experiment loaded. When you expand the Load Objects node, a list of all load objects is displayed with various messages about their processing. When you expand the node for an experiment, two areas are displayed: a Notes area and an Info area.
The Notes area displays the contents of any notes file in the experiment. You can edit the notes by typing directly in the Notes area. The Notes area includes its own toolbar with buttons for saving or discarding the notes and for undoing or redoing any edits since the last save.
The Info area contains information about the experiments collected and the load objects accessed by the collection target, including any error messages or warning messages generated during the processing of the experiment or the load objects.
The bottom panel lists error and warning messages from the Performance Analyzer session.
The Inst-Freq (instruction-frequency) view shows a summary of the frequency with which each type of instruction was executed in a count-data experiment, which is collected with collect –c. The view also shows data about the frequency of execution of load, store, and floating-point instructions. In addition, the view includes information about annulled instructions and instructions in a branch delay slot.
The MPI Timeline view shows a set of horizontal bars, one for each process in the MPI experiment, with diagonal lines connecting them that indicate messages. Each bar has regions colored according to the MPI function they are in, or indicating that the process is not within MPI (that is, it is elsewhere in the application code).
Selecting a region of a bar or a message line shows detailed information about the selection in the MPI Timeline Controls window.
Dragging the mouse causes the MPI Timeline view to zoom in on the horizontal (time) axis or the vertical (process) axis, depending on the predominant direction of the drag.
You can print an image of the MPI Timeline to a .jpg file. Choose File → Export and select Export as JPEG.
The MPI Timeline Controls window supports zoom, pan, event-step, and filtering for the MPI Timeline view. It includes a control to adjust the percentage of MPI messages shown on MPI Timeline.
Filtering causes data outside the current field of view to be eliminated from the data set shown in the MPI Timeline view and the MPI Chart view. Click the Filter button to apply a filter. Use the back-filter button to undo the last filter and the forward-filter button to reapply a filter. Filters are shared between the MPI Timeline view and the MPI Chart view but are not applied to other data views.
The message slider can be adjusted to control the percentage of messages displayed. When you select less than 100%, priority is given to the most costly messages. Cost is defined as the time spent in the message's send and receive functions.
The MPI Timeline Controls window also shows the details for a function or message selection from the MPI Timeline view.
The MPI Chart view shows charts of the MPI tracing data displayed in the MPI Timeline view. It displays plots of data concerning MPI execution. Changing the controls in the MPI Chart view and clicking Redraw causes a new chart to be displayed. Selecting an element from a chart shows more detailed information about that element in the MPI Chart Controls view.
Dragging the mouse causes the MPI Chart view to zoom in on the rectangular area defined by the drag.
You can print an image of the MPI chart to a .jpg file. Choose File → Export and select Export as JPEG.
The MPI Chart Controls window has a set of drop-down lists to control the type of chart, the parameters for the X and Y axes, and the Metric and Operator used to aggregate the data. Clicking Redraw causes a new graph to be drawn.
Filtering causes data outside the current field of view to be eliminated from the data set shown in the MPI Timeline view and MPI Chart view. To apply a filter, click the Filter button. Click the back-filter button to undo the last filter; click the forward-filter button to reapply a filter.
The MPI Chart Controls window is also used to show the details for a selection from the MPI Chart view.