This topic describes peculiarities of analyzing Visual Basic 6.0 applications with the Allocation profiler. Profiling of Visual Basic .NET applications does not differ from profiling of other .NET applications. For more information on this, see the description of the Allocation profiler and the Profiling .NET Applications - Specifics topic.
Profiling Memory Management Functions
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 that is part of Visual Basic’s runtime library. The runtime memory manager requests large blocks from the system, and then releases them when it is needed. It then deals on its own with the application’s memory-allocation calls. This improves functioning speed, and most importantly, allows you to avoid system memory thrashing (frequent allocations and de-allocations of small blocks).
The Allocation profiler traces calls both to VB memory manager’s functions and memory management functions provided by Windows API. For information on profiling system memory management functions, see Tracing System Memory Management Functions. As for runtime memory management functions, the profiler traces calls to the following:
-
__vbaRedim
,__vbaFreeObj
,__vbaStrCopy
,__vbaAryDestruct
-
__vbaFreeStr
,__vbaNew
,__vbaStrMove
These functions are called upon creation and reallocation of arrays, upon creation of classes that refer to COM objects, upon creation of classes with string fields, and so forth.
Profiling Classes (Memory Blocks)
Creation and deletion of VB classes is traced as creation and deletion of memory blocks. That is, the profiler results do not include the names of leaked VB classes; the leaked classes (if any) are reported under the VB native memory class name (with a complete call stack for each leaked instance). See also Allocation Profiler - Results of the Objects Category.
The Visual Basic memory manager allocates memory when a new object is created in your application. When the application is closed, the memory manager automatically releases all memory blocks it allocated during the application run. Thus, the Allocation profiler will not report any memory leaks in your Visual Basic application.
However, this profiler, along with the Monitor panel, can be helpful if you want to explore how your application uses memory in real time. The profiler reports a call stack for each call to memory manager routines, so you can easily see calls to which functions and procedures increase the amount of memory used by your application. The call stack does not include rows for memory manager’s routines (these routines are internal routines of Visual Basic’s memory manager, so there is no need to know them, since they do not contain useful information).
Note that since the memory manager allocates large memory blocks and then distributes them according to memory allocation calls from the application, memory allocations made through the memory manager functions may not increase the total amount of memory allocated for the application.
Preparing Application
In order to profile a Visual Basic application with the Allocation profiler, you need to compile it with debug information. For a detailed description of how to configure the compiler, see the Compiler Settings for Microsoft Visual Basic topic.
Preparing AQTime Project
To profile Visual Basic 6.0 applications with the Allocation profiler, add the MSVBVM60.DLL library to your AQTime project (see Creating and Saving AQTime Projects to learn how to do this). By default, the DLL is in the <Windows>\System32 folder. If the DLL is not added to the project, AQTime will not start profiling.
See Also
Allocation Profiler
Monitor Panel
Tracing System Memory Management Functions
Compiler Settings for Microsoft Visual Basic