The project runtime client software has been improved to keep screen graphics (e.g., objects, images, fonts) in memory rather than load them from the hard drive each time a screen is opened. This makes opening and switching screens much faster, which in turn improves the overall run-time performance.

Devices that run the client software often have limited memory, however, so it is necessary to change the method of memory allocation as the memory becomes full.

Figure 1. Memory allocation states

When memory allocation is enabled (which it is by default in new projects) and your project is run, all unused objects are kept in memory so that project screens can be reopened or redrawn quickly. This method or state of memory allocation is called Always.

As the memory fills with objects, however, the amount of free memory decreases and may eventually reach the Dynamic Limit (i.e., the value configured in the Before starting dynamic allocation setting). When this happens, unused objects may be kept in memory but are removed if the space is needed for other objects that are actually being used. This method or state of memory allocation is called Dynamic.

As the memory continues to fill with objects — typically because the client has many project screens open and therefore many objects being used — the amount of free memory decreases until it finally reaches the Critical Limit (i.e., the value configured in the Before disabling allocation setting). When this happens, all unused objects are removed from memory and memory allocation is disabled until you restart the project. This method or state of memory allocation is called Critical.

Performance control has default settings that should work for most projects running on most clients, but if you have problems, you can adjust the settings for your project or even disable memory allocation altogether.

To configure the performance control settings:

You can monitor memory allocation during run time by calling the function GetPerformanceMetric.