Quantify can record performance data using the following levels of detail:
Line: Line level provides detailed line-by-line performance data. Debug line data must be available for Quantify to identify source-code line numbers. Measuring performance at this level requires the most overhead, and so takes the most time to collect. Data collected at this level can be displayed in the Annotated Source window.
§ For Visual C++ and Visual Basic native-code (unmanaged) programs, Quantify computes the total machine cycles required to execute each source line, based on machine type.
§ For Visual Basic p-code programs and for .NET managed code, Quantify tracks the elapsed time for each line. Line level data is not available when you profile Visual Basic p-code programs.
Function: Function level provides the same level of accuracy as Line level, but less detail. This level is useful when you don't need to know how individual lines perform.
§ For Visual C++ and Visual Basic native-code (unmanaged) programs, Quantify computes the total machine cycles required to execute each function or procedure. For native-code programs, Quantify must have debug symbol data available for identifying functions.
§ For Visual Basic p-code programs, and for .NET managed code, Quantify tracks the elapsed time for each procedure.
Time: This measurement type is a distinct type only for native code, because for .NET code Quantify collects all data by timing. With this type of measurement, Quantify records the amount of time spent in each function, which can provide quicker runtime performance of the program during profiling than computing machine cycles. This is because Quantify records function time when the function exits, instead of incrementally computing function time at each internal branch or function call. Only data for exported functions is recorded. The time taken by internal, non-exported functions is attributed to the exported functions that called them. The data is accurate but, because it is influenced by processor state and memory effects, is not always repeatable. Timing is a good choice for code you cannot modify or directly affect, such as system or third-party modules.
Quantify provides several methods for timing functions: user time, user + kernel time, kernel time, and elapsed time. You can also choose to ignore timed functions altogether, in which case Quantify simply reports the time as zero (0).
The default timing method Quantify uses for a function, and the measurement type it reports for the function, depend on the category into which the function falls.
Function |
Function |
Default timing method |
Reported measurement type |
Functions in user modules |
Functions in modules that you choose to time, rather than count machine cycles |
User time |
|
Functions in system modules |
System functions other than blocking and waiting functions |
User + kernel time |
|
Functions that block or wait |
System functions that wait on I/O, such as WriteFile or ReadFile, or those that block on synchronization objects, such as WaitForSingleObject |
Elapsed time |
You can use the PowerTune and Run Time tabs in the settings dialog box to specify how you want Quantify to measure the performance of functions.
Notes:
§ The Time measurement type is not supported for selective instrumentation.
§ When you are profiling native-compiled (unmanaged) programs, you can use the Module Instrumentation dialog box to specify timing methods for individual modules.
§ When Quantify collects performance data by counting cycles, it excludes the profiling process itself. The numbers you see are the time your program would take without Quantify.
§ You must rerun a program if you select a different measurement type or timing method.
§ Quantify's output includes .Root., representing the total time of the program, .main_nnn., representing the main thread, .thread_nnn., and .fiber_nnn.. These items are generated by Quantify and do not incur time themselves. Quantify reports their measurement type as Other.
§ If you choose to time functions in an executable, the only data Quantify includes for the executable is the .exe's entry point. The entry point's function time includes the function time of the other functions in the .exe.
§ For native-compiled programs, Quantify also requires relocation data to collect data at line or function level. If relocation data is not available for an .exe, Quantify times the functions. Only the .exe's entry point, or the module's exported functions, are included in the dataset; the time of non-exported functions is attributed to their exported callers.
(C) Copyright IBM Corporation 1993, 2009.