LabVIEW handles many of the memory details that you normally must account for in a conventional, text-based language. For example, when you add new information to an array or a string, LabVIEW allocates new memory to accommodate the new array or string. When that data is no longer needed, LabVIEW deallocates the associated memory. However, keep the following memory considerations in mind when using LabVIEW:

• Allocating memory can cause jitter.
• RT targets can run out of memory.
• RT targets can run out of contiguous memory. Contiguous memory is a consecutive set of memory addresses assigned to a process. (NI Linux Real-Time) Running out of contiguous memory is less likely on NI Linux Real-Time targets because these targets have memory management units.

Designing Memory-Conscious VIs

NI provides the following recommendations to design memory-conscious VIs for RT targets:

• Always preallocate space for arrays equal to the largest array size that you might encounter.
• When defining LabVIEW classes for use on RT targets, avoid defining default values that require a large amount of memory, such as large arrays or strings. Note that when using LabVIEW classes on RT targets, the Request Deallocation function can actually allocate memory in certain cases. If the default value of the class includes large, variable-size data structures, such as large arrays or strings, and the application sets the value of the class instance to include smaller arrays or strings, the Request Deallocation function allocates memory because the function resets data to the default value of the data type.

Contiguous Memory Conflict Example

The following illustration shows how failing to preallocate sufficient space for the largest array size in your application can lead to a contiguous memory conflict.

When you reboot or reset an RT target, the RTOS and the RT Engine load into memory. The RT Engine uses available memory for running RT target VIs and storing data.

ArrayMaker.vi creates Array 1. All elements in Array 1 must be contiguous in memory. The RTOS reserves a contiguous memory space equal to the memory used for Array 1.

The RTOS reuses the same memory addresses if you stop a VI and then run it again with arrays of the same size or smaller. In diagram 3, ArrayMaker.vi creates Array 2. The RTOS creates Array 2 in the reserved memory space previously occupied by Array 1. Array 2 is small enough to fit in the reserved memory space that was allocated to Array 1, so it does not create a contiguous memory conflict. The extra contiguous memory used for Array 1 remains in the reserved memory space.

When ArrayMaker.vi runs for a third time with a larger array or if another VI generates a larger array, the RT Engine must find a large enough contiguous space. In diagram 4, ArrayMaker.vi must create Array 3, larger than the previous arrays, in the available memory. Even when ArrayMaker.vi stops running, the RT Engine continues to run and previously reserved memory is not available. If ArrayMaker.vi runs a fourth time and attempts to create an array larger than Array 3, the operation fails. There is no contiguous memory area large enough to create the array because of the memory fragmentation.

To avoid the contiguous memory conflict in diagram 4, you can preserve memory space by preallocating array space equal to the largest use case.