Allocation Profiler - Analyzing C++Builder 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 the 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 the runtime memory manager and calls to 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:

• VCL

  • 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.

  To enable AQTime to profile the above-mentioned routines in C++Builder 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.

• C++

  • new, delete

  • new[], delete[]

  • malloc, calloc, realloc

  • expand, free

The profiler can also show class names reporting object leaks. Note, that an object will be reported with its class name if the following conditions are met:

• VCL

  • The class must be inherited from TObject.

  • The class must introduce new methods or override methods derived from TObject.

  • The class methods should be called in 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.

• C++

  • The class must have a constructor written in code or generated by the C++ compiler (compilers typically generate the constructors, if a class is a descendant of another class).

  Classes that do not have a constructor are reported under the C++ native memory class name (with a complete call stack for each leaked instance). See Allocation Profiler - Results of the Classes Data Category for more information.

In order to profile a C++Builder 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 C++Builder, see the topics of the Compiler Settings for Native Applications section.

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, rtl60.bpl for C++Builder 6. 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 start 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 (i.e. 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 libraries option enabled. You can change the option on the Linker tabbed page of the Project Options dialog.