Memory profiling allows you to identify and diagnose memory consumption issues in your ABL code. When enabled for memory profiling, the AVM generates reports, referred to as recordings, to help you analyze the captured memory usage data. Snapshots can be generated automatically at a certain cadence or programmatically in your code.

Memory profiling can help answer these questions about the memory use in your code:
  • What was allocated?
  • Where was it allocated (call stack)?
  • When was it allocated?
  • How big is it?
  • What is it scoped to (if it is scoped)?
  • How many others like it are there?
  • How many others have the same call stack?
  • When did it go away?

Memory profile data consists mostly of dynamic application objects. Data is collected for everything that can be created using the CREATE widget statement, .p procedures, and any class that can be instantiated with NEW. Temp-tables, widget pools, database connections, and other application objects are also tracked.

Memory profiling consists of:
  1. Generating a memory profiler recording.
  2. Importing and analyzing the memory profiler recording. You can visualize the memory usage of your application code using the OpenEdge Memory Profiler tool, which enables you to examine how an application utilizes memory over time and at specific intervals.

    For more information, see Use the OpenEdge Memory Profiler Tool.

Note: A memory profiler recording must be finalized before it can be imported for processing and analysis. This means the ABL client processes (such as prowin, _progres, and Progress Application Server (PAS) for OpenEdge agents) must complete before the recording is ready. Memory profiling does not support streaming import while the session is running.