#### Call Graph

The call graph collector provides information on how many times a function calls some other function and the amount of time each call takes. It keeps track of every function that executes, its parent and child functions and the total time spent in each call. In order to be able to do this, the call graph collector instruments the specified application and all the other modules and DLLs that the application calls. Unfortunately, instrumentation adds an overhead during collection of data to gather the additional information

See the VTune™ Performance Analyzer online help for more information.

#### Counter

A feature of modern processors are built in counters that have the ability to gauge an application's performance and interaction with the rest of the computer system by counting various events. Counters consist of circuitry to detect events, registers to accumulate counts, and triggers to interrupt the processor at certain count thresholds. By observing counter accumulation and correlating it to source code location, software developers can identify statements or expressions that can be tuned to use system resources more efficiently.

The kinds of events that can be counted include: periodic time duration, cache misses, floating point exceptions, data misalignments, page faults, mispredicted branches, and many others.

See the VTune™ Performance Analyzer online help for more information.

#### Counter Monitor

The counter monitor collector uses the operating system (OS) and hardware performance counters installed on your system to measure the performance of the different OS and hardware objects on your system.

The counter monitor data displayed as a function of time (unlike sampling which is a function of instruction address) helps you to analyze your system performance and resource utilization issues such as memory and disk usage. Note, however, that the counter monitor does not record any application specific information such as instruction addresses or function call, so does not associate the counter information with any specific software module executing on your system. You can, however, run sampling along with the counter monitor data collector, and drill down from the counter monitor view to the sampling views to see what modules were executing when the specific event, for example, page faults or cache misses were highest.

See the VTune™ Performance Analyzer online help for more information.

#### Critical Path

The critical path is the parent-child call path originating from the root that took most time. Nodes on the critical path are highlighted in red squares in the call graph view.

See the VTune™ Performance Analyzer online help for more information.

#### Skid

Event skid is the recording of an event not exactly on the code line that caused the event. Event skids may even result in a caller function event being recorded in the callee function.

See the VTune™ Performance Analyzer online help for more information.

#### Hotspots

A hotspot is a section of code that is generating a significant number of events. Typically, time is the more important event to consider when looking for hotspots. Other events like Mispredicted Branches, Cache Misses, and Instructions Retired can also be displayed as hotspots. Analysis of these events may provide clues on how to make performance improvements.

Hotspots can be identified because the VTune™ Performance Analyzer collects data on the amount of time spent in executing a function or an event occurring during the execution of an instruction. Modules or functions with a high number are displayed as hotspots. The VTune analyzer displays the collected data in the form of a graph or table and hotspots are displayed as peaks or longer than expected bars in the graphs.

See the VTune™ Performance Analyzer online help for more information.

#### Logged Data View

The logged data view displays data logged during an Activity.

From the logged data view you can drill down to sampling data. You can also view a report of samples collected for each module during a selected time range. The exact mechanism for selecting the time range is dependent on the chart control used.

Additionally, you can select values to analyze in the detailed view. Again, the value selection mechanism depends on the chart control used. Once values are selected, open the detailed view for further analysis.

See the VTune™ Performance Analyzer online help for more information.

#### .PRF File

During the call graph profiling session, the VTune™ Performance Analyzer keeps track of the functions entered and exited in your application, establishes a relationship between the parent and child functions, and saves the data to a .prf file. It creates separate .prf files for each profiling session. At the end of the profiling session, it analyzes the data and displays the call graph view. The .prf file header contains information whether this file provides call site information.

See VTune™ Performance Analyzer online help for more information.

#### Project

Contains the project folder, Activities and Activity results. The project is contained in a project file (.vpj)

See the VTune™ Performance Analyzer online help for more information.

#### Project Navigator window

The Project Navigator window displays a hierarchical list of a project and the items contained in a project.

These are the main items in the Project Navigator window hierarchy:

Item Name | Definition
Project | Contains one or more Activities, Activity results or folders.
Folder | Enables adding another level of organization into your projects. You can place Activities, Activity results or other folders within a folder.
Activity | Used to perform the actual collection of data for later use in analysis and tuning. An Activity contains one or more data collectors, each of which collects a specific type of data. In addition, Activities may contain one or more application/module profiles, which contain information about how an application is executed.
Activity result | The results of running an Activity. An Activity may contain multiple data collectors, and each data collector, when finished collecting data during the run of an Activity, typically creates an Activity result which represents the data that it collected. Some data collectors may create an additional level of items below the Activity result. These additional items usually enable easier examination of certain aspects of the data.

See the VTune™ Performance Analyzer online help for more information.

#### Retired Instruction

Modern processors have a component that reads ahead in the instruction stream while the rest of the processor is still processing an instruction that it had read earlier. Instructions are counted as "retired" when they are actually executed and their results completed (written to registers, completed a machine state change, or sent some data out to memory). Other instructions, that have not yet been executed may be in various states (being decoded, being scheduled for action, etc.) and are not yet counted as retired until they are finished executing.

See the VTune™ Performance Analyzer online help for more information.

#### Runtime View

The runtime view is generated only when an Activity containing the counter monitor collector is started. While counter monitor data is continually updated in runtime view, you may pause and resume collection of data to the log file. Once you stop the data collection and close the runtime view, only the data saved to the log file can be viewed in the logged data view.

See the VTune™ Performance Analyzer online help for more information.

#### Sampling

The sampling collector is non-intrusive meaning it does not slow down your application when collecting data. It collects and records samples of the instructions executing on your system, including the operating system (OS) and your application modules at periodic user-specified intervals. The samples are collected at the specified number of OS timer interrupts or after a specified number of Central Processor Unit (CPU) events, such as cache misses. At the end of the collection, the VTune™ Performance Analyzer matches the samples with the corresponding instruction addresses, and records the total number of samples collected per module and function that executed on your system. The sampling data helps you analyze system-wide performance as well as determine the most CPU intensive functions or modules in your application.

See the VTune™ Performance Analyzer online help for more information.

#### Source Range

The VTune analyzer displays the source file in which the function appears. When the VTune analyzer doesn't find the source file, it displays the disassembly code with the region surrounding the target address.

See the VTune™ Performance Analyzer online help for more information.

#### Source View

The source view shows source code and/or the disassembly of one source file in the monitored module, annotated with additional information about the code.

See the VTune™ Performance Analyzer online help for more information.

#### Activity

Used to perform the actual collection of data for later use in analysis and tuning. An Activity contains one or more data collectors, each of which collects a specific type of data. In addition, Activities may contain one or more application/module profiles, which contain information about how an application is executed.

See the VTune™ Performance Analyzer online help for more information.

#### Tuning Assistant

The Intel® Tuning Assistant provides context-sensitive tuning advice. It interprets operating system and processor-based performance counter data and provides insights on potential performance problems.

See the VTune™ Performance Analyzer online help for more information.

#### Wizards

New project wizards can help you configure VTune analyzer for a specific or multiple types of data collection.

See the VTune™ Performance Analyzer online help for more information.