To access this pane:
Click the Bottom-up sub-tab in the result tab. From the Hardware Event Counts viewpoint, click the PMU Events or Uncore Events sub-tab.
| Use the Bottom-up pane to view and analyze performance data for each program unit per metric. This pane is the basic part of the Bottom-up, PMU Events, and Uncore Events windows. |
Call Stack
Each row of the Call Stack column corresponds to a grouping level (granularity) of program units (module, function, synchronization object, and others). You can change the grouping level using the Grouping drop-down menu at the top of the Bottom-up pane. The default grouping level for most of the analysis types is Function.
Analyze a tree hierarchy of the call stacks that lead to the selected program unit. Click the plus sign 
to expand a row and view caller trees for each program unit. Each tree is a call stack that called the selected unit. The time value for a row is equal to the sum of all the nested items from that row.
Each tree lists all the program units that had only one caller in the same row, with an arrow 
indicating the call relationship. Program units that had more than one caller are split so that each caller has a separate row with the callers to that callee. The full information on the stack is shown in the Call Stack pane.
Note
Call stack information is always available for the results of the user-mode sampling and tracing collection. It is also available for the results of the hardware event-based sampling collection, if you enabled the Collect stacks option during the analysis configuration. Otherwise, the Call Stack column for the event-based results shows "Unknown" entries in the call tree. See the Interpreting Stack Data topic or more details.
In the Uncore Events window, the Bottom-up pane does not show call stacks for the functions but provides a flat list of functions instead. Uncore events happen on structures shared between all CPUs in a package (for example, 10 CPUs on a single package). This makes it impossible to associate any single uncore event with any code context.
If you see
[Unknown frame(s)]identifiers for the functions, it means that the VTune Amplifier could not locate symbol files for system or your application modules. See the Resolving Unknown Frame(s) topic for more details.If the VTune Amplifier does not find debug information in binaries, it statically identifies function boundaries and assigns hotspot addresses to generated pseudo names
func@addressfor such functions, for example:![]()
Performance Metrics
By default, all program units are sorted in a descending order by the Data of Interest column providing the most performance-critical program units first. Each data column in the table corresponds to a performance metric. The list of performance metrics varies depending on the analysis type and selected viewpoint.
You may click a column header to sort the table by the corresponding metric.
Infotips
Infotips show up as pop-up windows when you mouse over a column header (metric) or a performance issue highlighted in pink.
Use This | To Do This |
|---|---|
Metric infotip | See the metric description and a formula used for metric calculation (if available). |
Issue infotip | See the description of the detected issue, tuning advice, and a formula used to calculate the threshold for this metric. If the metric value exceeds the threshold and the program unit is a hotspot, the VTune Amplifier highlights this value in pink as performance-critical. |
Example
This example shows the contribution of the callee functions to the caller function's metric value. The second hotspot, DD_BltBackToPrimary function, has one caller Paint that is called in three call sequences.
The time values for the nested items under Paint equal the time value for this row:
0.608 +0.023 + 0.012 = 0.643