AQTime Profilers

Profiler Categories

Static and Runtime Profilers

Support for Different Code Types

Brief Profiler Descriptions

AQTime profilers are organized into the following categories:

Profilers of the Static Analysis category do not run your application. Static Analysis, Sequence Diagram Link and Unused VCL Units explore debug information and Platform Compliance analyzes the import function table included in the executable.

The other profilers launch your application. They gather data while the application is running and provide results when the run is over or when you select Run > Get Results from the main menuAQTime > Get Results from the main menuAQTime > Get Results from the main menu. The only exception is the Exception Trace profiler - it displays results in real time.

Below are brief descriptions of AQTime profilers:

• The Performance profiler is meant to be used to find bottlenecks in your application and for determining what causes these bottlenecks. During the run, this profiler gathers lots of statistics on each routine included in profiling tasks: how many times the routine was called, what function called the routine and what functions it called, how many exception occurred during the routine execution, etc. In addition, the profiler also measures such application characteristics as the function execution time and the number of CPU cache updates. The value the profiler measures depends on the Active counter option. Currently, the profiler includes the following counters:

  Elapsed Time User Time User+Kernel Time CPU Mispredicted Branches CPU Cache Misses Context Switches 64K Aliasing Conflicts

  Split Load Replays Split Store Replays Blocked Store Forwards Replays Soft Memory Page Faults Hard Memory Page Faults All Memory Page Faults

  The Elapsed Time, User Time and User+Kernel Time counters time application functions. Depending on the counter in use, the resultant time may (or may not) include time spent on executing the operating system code, time spent on switching between threads, etc. The CPU Mispredicted Branches counter reports whether your code can be well predicted by the CPU's branch prediction unit. The CPU Cache Misses counter lets you determine whether hotspots in your applications are caused by an excessive number of CPU cache updates. The Context Switches counter calculates the number of context switches that occur during the function execution. Other counters let you determine whether your application algorithms used to work with memory are effective and do not cause performance bottlenecks. For a complete description of the counters and counter limitations, see Counters Overview.

  For .NET applications, the Performance profiler also lets you determine how much the .NET runtime contributes to function results: the profiler measures the time spent for Just-in-Time compilation and garbage collection and displays these times as <JIT compiler> and <Garbage collector> routines in the profiler results.

  These routines as well as counters and certain columns in profiler results help you determine what caused a bottleneck during the application run. That is, you can use the Performance profiler not just to establish the fact that a bottleneck exists, but to find the cause of the bottleneck as well. For more information on this, see Search for Bottleneck Reasons .

  The Performance profiler can analyze your code at two levels of detail: routine and line. To profile routines at line level, the application must be compiled with debug information. See How AQTime Profilers Use Metadata and Debug Information.

  The profiler collects separate results for each thread in a multithreaded application. It can organize results by operating system threads as well as by .NET runtime threads. See Profiling Multiple Threads for more information.

  We would like to note once again that Performance profiler supports the profiling of both managed and native (i.e. unmanaged) modules (see also Profiling Mixed-Code .NET Applications). This lets you profile, for example, unmanaged dynamic link libraries along with the .NET modules that use these libraries.

• The Sampling profiler polls applications at certain time intervals to measure how long it takes the application to execute each of its routines. You can use the data the profiler collects to estimate your application performance and detect potential bottlenecks. This profiler is similar to the Performance profiler. The data it collects is less detailed but it works much faster than the Performance profiler. This makes the Sampling profiler suitable for the initial exploration of application performance.

• The Allocation profiler traces the memory usage within your applications during the profiler run. It reports how many objects of each class exist, how many memory blocks are allocated, how much memory is occupied by objects and blocks, etc. The profiler gathers a lot of information: it traces call stacks for objects and memory blocks, determines references between different managed objects, etc. Using the Allocation profiler you can easily find memory leaks in your unmanaged (i.e. non-.NET) applications. Although the common language runtime (CLR) reclaims all the memory allocated for the objects of a managed application when the application run is over, this profiler can still be used with such applications. You can employ it to trace objects during the application run. Using the Monitor panel when running the Allocation profiler, you can view the allocation information in charts and grids, which helps you trace the memory usage in real time.

• The Resource profiler follows how your application exploits Windows resources (fonts, brushes, bitmaps, and other graphic components, registry, COM objects, print spooler and so on) during the profiler run. It reports what these resources are, how many resources of each type were created up to given moment, how many of them still exist, how much memory is occupied by the resources in use, what errors in resource management functions occurred during the run, etc. The profiler can help you find resource leaks (unreleased resources) and resource errors in managed and unmanaged applications. For each occupied resource instance, the profiler keeps its call stack of functions calls, which lets you easily discover how this resource instance was allocated.

• The Reference Count profiler tracks the number of references to COM objects that implement one or several interfaces. The profiler traces the creation and deletion of references and allows you to pinpoint unreleased references or those that were released prematurely.

• The Coverage profiler determines whether the function or line was executed during the application run. It also counts the number of times a routine (or line) was executed during the profiler run. Using this profiler you can easily find what application areas your tests “cover” and what was left untested.

• The Light Coverage profiler determines whether a routine or a line was executed during the profiler run. This profiler is similar to the Coverage profiler but it does not track the hit count and it does not allocate results by threads.

• The Static Analysis profiler will tell you which methods exist in the application, where they are called from in the source code and what they call in turn. This does not tell you if and when the calls will execute, but it does give a full report of method inter-dependence in the source. See it as an intelligent overview browser of the debug information that is linked into the executable.

  A powerful addition to the Static Analysis profiler is the PE Reader panel. It also performs the analysis of your application statically and provides detailed information about modules used by the application. For example, it shows tables of imported and exported routines, module base addresses, entry points of routines and their offsets in the import address table, etc.

• The Sequence Diagram Link profiler builds a UML-style diagram of function calls in the profiled application and displays this diagram in Microsoft Word or Microsoft Visio.

• The Platform Compliance profiler reports what Windows versions support the API calls in the source.

• The Exception Trace profiler monitors the application execution and, if an exception occurs, displays the exception call stack in the Event View panel. Since Exception Trace does not slow down the application execution, it can be very convenient to use if your main goal is tracking down an application exception.

• The Failure Emulator profiler traces whether the code of your application contains lines preventing the application from unexpected failures. For example, you can check whether the application that has the .txt file as an input parameter behaves correctly (shows an informative message or something else) when you try to specify the .bmp file as a parameter for it. If the code contains needed lines, the application will not fail. Otherwise, conditions for the application failure are met and you can see how your application behaves in an unexpected situation.

  To simulate such failures, the profiler includes various types of standard failures (for example, you can simulate failures related to the COM technology, registry and so on). For more information on available failure types, see the description of the Add New Failure Emulation wizard.

• The Function Trace profiler traces the routine calls during the profiler run and logs call stacks for each call. Native-code and managed application profiling is supported (including 64-bit code support). It provides you with comprehensive information on how any routine is invoked, which parameter values are passed to it and some other routine characteristics. This profiler provides an opportunity to process actual call stack data in real-time. Source code modifications are not needed - Function Trace automatically performs actions, that otherwise, could only be done by introducing hundreds of trace-message lines in the source code.

• The BDE SQL profiler measures and logs the execution time of SQL queries or SQL stored procedures called through the BDE (Borland Database Engine). Using the Details panel of the profiler you can view the sequence of functions that call a BDE operation.

• The Load Library Tracer profiler traces the loading and unloading of dynamic link libraries during the application execution. Using the profiler you can detect which libraries are loaded and unloaded too often (and thus impact the overall application performance) and optimize the use of them.

• The Unused VCL Units profiler detects standard VCL and user units that were included in the application but are not used by it. Removing these units will decrease the application size without losing any functionality.