Allocation Profiler - Analyzing Delphi Applications

Profiling Memory Management Functions

Profiling Classes

Preparing Application

Preparing AQTime Project

Getting Detailed Call Stack

The Allocation profiler tracks functions that allocate or de-allocate memory. In general, applications can do this in two ways: they can use system memory management calls, or they can call the runtime memory manager, which is part of the VCL runtime library. The runtime memory manager requests large blocks from the system, and then eventually releases them. After that, it works on its own with a lot of memory-allocation calls from the application. This improves speed, and more importantly, allows you to avoid system memory thrashing (frequent allocation and de-allocation of small blocks).

The Allocation profiler traces calls to runtime memory manager and system memory management functions. For information on profiling system memory management functions, see Tracing System Memory Management Functions. The profiler traces calls to the following runtime memory management functions:

• GetMem, ReallocMem, FreeMem

• GetMemory, ReallocMemory, FreeMemory

• SysGetMem, SysReallocMem, SysFreeMem

The New and Dispose routines are not traced explicitly. They call GetMem and the profiler traces these calls.

In order for AQTime to profile the above-mentioned routines in Delphi applications, you may need to add certain modules to the Setup panel in addition to your modules. This depends on compiler options that were enabled when you compiled your application, specifically enabling/disabling the Build with runtime packages option. More information on this is below. Please read it, as this information is important. If you do not read it, you may get empty results.

The profiler is able to show the class names when creating and deleting VCL objects. Note, that an object will be reported with its class name if several conditions are met:

• The class is inherited from TObject.

• The class introduces new methods or override the inherited TObject methods.

• You call those methods from your code. (Otherwise they can be excluded from the debug information by the compiler.)

In any other case, for example, if class only introduces properties and fields, the leaked classes (if any) are reported under the VCL native memory class name (with a complete call stack for each leaked instance). See also Allocation Profiler - Results of the Classes Data Category.

In order to profile a Delphi application with the Allocation profiler, you need to compile it with debug information. Note that to provide the Allocation profiler with access to basic VCL classes, you must uncheck the Build with runtime packages option. If you want to leave this option enabled, you need to include certain libraries in your project (for more information on this, see Preparing AQTime Project).

For a detailed description of how to configure the compiler in different versions of Delphi, see the topics of the Compiler Settings for Native Applications section.

The Allocation profiler tracks both calls to runtime memory manager and system memory management functions (see above). This section describes peculiarities of profiling runtime memory manager functions.

The memory manager can be located in the profiled module or in one of the packages. This depends on the Build with runtime packages compiler option (you can change it on the Packages tabbed page of the Project Options dialog):

• If this option is turned on, the memory manager code is not included in the executable and the application uses the memory manager from the .bpl runtime package located in the <Windows>\System32 folder, for instance rtl70.bpl for Delphi 7. If you want to profile calls to the memory manager, you should add the appropriate package to the Setup panel. The package can be compiled without debug information. See the topics of the Compiler Settings for Native Applications section to find out what package is needed for your application.

  At the beginning of the Allocation profiler, AQTime checks whether memory management routines are contained within packages. If the check is successful, it shows a message informing you which packages should be added to your AQTime project.

• If the “Build with runtime packages” option is off, the memory manager is located within the profiled executable. In this case, there is no need to add .bpl modules to the Setup panel.

When AQTime tracks the hierarchy of function calls that led to an object creation or allocation of a memory block, it traces only those routines for which it can find debug information. When you create a new class instance (that is, an object), a memory management routine is not called directly by the class constructor. A call to it can be made by other routines which the class constructor calls. These routines typically locate in VCL units.

Since VCL units may be compiled without debug information, the call stack may not hold all the routines, which were called, or it may hold partial information for them (for instance, information about source lines can be absent). Therefore, to obtain more detailed call stack, compile your application with the Use Debug DCUs option enabled. You can change the option on the Linker tabbed page of the Project Options dialog.