Memory Management in LabVIEW Real-Time

LabVIEW Real-Time transparently handles many of the details that you normally deal with in a conventional, text-based language. One of the main challenges of programming with a text-based language is memory usage. In a text-based language, you must allocate memory before you use it and deallocate it when you are finished. You also must be particularly careful not to accidentally write past the end of the memory you have allocated. Failure to allocate memory or to allocate enough memory is one of the biggest mistakes that programmers make in text-based languages. Automatic memory handling is one of the chief benefits of LabVIEW Real-Time. However, because it is automatic, you have less control over it. For example, functions that generate data allocate storage for that data. When data is no longer needed, LabVIEW Real-Timedeallocates the associated memory. When you add new information to an array or a string, LabVIEW Real-Time allocates new memory to accommodate the new array or string.

In general, memory allocations within a time-critical loop will induce jitter and affect the deterministic properties of a LabVIEW Real-Time program. All memory allocations must be removed to guarantee robust hard real-time performance. You must preallocate your arrays outside of the loop if you want your application to run deterministically. When you use Build Array functions inside of a loop, a memory allocation is made every time data is written to the array. Consider the following scenario, which illustrates how memory allocation can induce jitter.

Suppose you have two threads in LabVIEW Real-Time executing concurrently – one involving a time-critical loop, which must maintain a high level of determinism, and another involving a non-time-critical loop that communicates in some respect with the time-critical loop. Furthermore, suppose each thread requires dynamic memory allocation because they are both building arrays, which grow inside a loop. Thus, LabVIEW’s memory manager must allocate additional memory to each thread as the loops continue to run, but the memory manager can only allocate memory for one thread at a time. Therefore, if at any time both threads request additional memory by virtue of the Build Array function (or any other VI that does not reuse its input buffer), one thread will have to wait on the memory manager while it dynamically allocates new memory to the other thread (see Figure below). A situation like this could induce jitter in a time-critical loop if the memory manager is busy allocating memory to other threads, such as the non-time-critical loop mentioned above, if the time-critical loop requests additional memory at an inopportune time. This is known as a priority inversion.



As another performance consideration, try to cast data to the proper data type, because every time LabVIEW has to perform a type conversion, either implicitly or explicitly, a copy of the data buffer is made in memory in order to retain the new data type after the conversion. Use the smallest data type possible, and if you need to convert the data type of an array, by all means, try to do that conversion before the array is built. Also keep in mind that a function output reuses an input buffer only if the output and the input have the same data type representation, and in the case of arrays, the same structure and number of elements. This ability for a function to reuse buffers is called inplaceness. Furthermore, for each global variable used in a program, an extra copy is placed in memory on program start up. This causes extra memory allocation. Utilizing inplaceness and reducing the use of global variables will improve the efficiency and performance of real-time applications because they require fewer calls to LabVIEW’s memory manager for new memory. Consequently, inplaceness and good memory management reduces jitter in loops, thereby improving the overall determinism of the application.

Related Links:
Memory Management in LabVIEW

Reader Comments | Submit a comment »