LabVIEW In-depth Exploration - Memory Management and Cache Reuse

Friends who have used the conventional C language know that C allows programmers to apply for memory, reallocate memory, and release memory. This provides great convenience for programmers, but also creates a lot of hidden dangers. It can be said that many inexplicable errors in the operation of C programs are related to memory leaks. The program may run for several hours without any problems, but suddenly an error occurs. For a more complex program, it is very difficult to track memory leaks, and it is often necessary to use third-party specialized memory analysis tools.

There are two most common memory errors in C:

1. Array out of bounds:

  int Array[10]; //The system automatically allocates 10*4BYTE space

  for(int i=0;i<100;i++) Array[i]=i; //There is no problem when writing the first 10 elements. If there are more than 10 elements, C will continue to write data to the continuous memory space.

  If the memory space is useless, there is no problem. If this memory space is occupied by the system or other applications, incorrect writing may cause the system to crash. It often prompts that an unexpected error has occurred. Newer operating systems generally do not crash, but will prompt a memory write error and the application will exit.

2. Allocated memory is not released (memory leak)

 int *p; //define integer pointer

 p=(int *)malloc(100*sizeof(int)); //Apply for 100*4 bytes of memory

 if(p==NULL) //The system cannot allocate, exit the program

{

   return (errro);

}

free(p); //Release the requested memory space If there is no such statement, calling this program repeatedly will cause more and more memory space to be occupied.

LabVIEW is completely different. Its memory allocation is automatically completed by the LV memory manager. Therefore, there is no problem of user memory release, nor is there an array out-of-bounds problem. In this case, is it meaningful to discuss LV's memory management?

The answer is: very important. People often complain that LV runs slowly and has poor performance. The main reason is improper memory usage.

LV is constantly allocating, reallocating and releasing memory, but these tasks are automatically performed by the LV memory manager. For users, they are performed in the background and are not controlled by users. At the same time, the work of the memory manager is very heavy and slow, and its large amount of meaningless work will lead to a sharp decline in program running efficiency.

The best way to improve LV memory usage is good programming style.

The memory space occupied by a VI is divided into four parts.

1. PANEL front panel

2. BLOCK DIAGRAM program flowchart

3. CODE SPACE code space

4. DATA SPACE data space

Code space refers to the space occupied by the machine code generated after the block diagram is compiled.

The data space includes the values ​​and default values ​​of front panel controls and indicators, constants, and dynamically defined data.

When a VI is opened, the panel space, code space and data space are loaded into memory, and the code space and data space of the sub-VIs of the VI are loaded into memory.

If you choose to display the block diagram, the block diagram space is also loaded into memory.

It can be seen that when a VI is opened, LV only loads the required parts, and the sub-VI only loads the code space and data space. Therefore, it is unnecessary to consider the front panel and flowchart of the sub-VI. As shown in the figure above, if the main VI is divided into multiple SUBVIs, the use of memory can be effectively saved. Because SUBVI no longer needs the front panel and flowchart, only the code space and data space are loaded into the memory, and when needed, LV can reclaim the data space memory and reuse it. When we open a very large program with few SUBVIs, the speed will be very slow. On the contrary, a large program with many SUBVIs opens very quickly. This is the reason.

When we write VI, we often need to check its memory usage. There are several ways:

1. Through the ABOUT dialog box, you can check the total memory allocated by the operating system for the LV. The total memory includes the memory occupied by the opened VI and the memory occupied by the LV itself. After opening the LV, record this value (the memory occupied by the LV itself), then edit your VI, and then check the ABOUT dialog box. The difference between them is the memory occupied by your VI. This method can roughly estimate the memory usage of your VI

.

 

 2: Use show vi property (CTRL+I) in the FILE menu to view the current VI's memory usage.
 

3. View through the Profile Window.

 

Summarizing the above content, several key points are drawn:

Because LV controls memory management, it is difficult to know how LV memory is allocated.

．Good programming style will improve LV memory usage.

. VI's memory usage is divided into four parts: PANALE, BLOCK, CODE, and DATA.

The following section analyzes in detail how these four parts of memory are used.

First, let's look at PANEL and BLOCK, which are the main parts that occupy memory.

The front panel is mainly composed of controllers and indicators. Each controller and indicator has its own copy of data. When editing, we can change the values ​​of controllers and indicators at will. Even if they are connected through data streams, as long as they are not running, the indicator will always keep the original value without new data streams. The data copies of controllers and indicators are called operation data, because their values ​​can only be changed through specific operations. The data (data stream) in the block diagram is called execution data, because it only works when VI is running. It can be understood as data on the line. [page]

 There is no operation data for a non-displayed sub-VI. If the front panel of the SUBVI is opened, the operation data of the controllers and indicators are included.

In the following cases, operational data will be included.

．Front panel open．

．The property nodes used by the block diagram program cause the front panel to be loaded into memory and may not be displayed, but it exists.

．Local variables read and write controllers and indicators．

． Set VI attribute, OPEN WHEN CALLED.

The operate data of BLOCK only occurs when BLOCK is displayed, and it can be ignored when compiling into an executable file.

The code space, including the code space of all sub-VIs, is loaded together with the main VI when it is loaded into the memory and exists for a long time. It contains the machine code compiled by the block diagram.

The code space of a sub-VI is generally small, but when there are more than a few hundred SUBVIs, the memory usage cannot be ignored. When you execute the main VI, this code will always exist regardless of whether it is useful or not.

If the SUBVI is called dynamically through the VI server, it is up to the user whether and when the code space is loaded. Therefore, the use of dynamic calling can effectively save memory, but at the same time, if it is called repeatedly, it will affect the running speed. Saving memory comes at the expense of speed.

LV memory management is automatic, but it is not completely uninterruptable. By studying its basic operating rules and combining them with our good programming style, we can improve its efficiency.

Let's look at some real examples. 

　
 

 Because the data type of the loop count terminal is I32, which occupies four bytes, 1000 data occupies 4K bytes, and the data flowing out of the loop occupies 4K of data space.

The top diagram is array indexing, which is a read operation. It does not change the data on the data stream, so no new memory needs to be allocated, but memory is reused. The bottom diagram is replacing array elements. The array will change after the replacement, because the three parallel replacements are independent and have no order, so LV has to allocate an additional 4K+4K bytes for 2 and 3, plus the 4K bytes allocated after the loop, so 1, 2, and 3 occupy a total of 12K.

 In this figure, replacement is to rewrite the data, but the index does not need to be rewritten. If replacement is performed first, 4K memory must be reallocated for the index part to avoid reading back the wrong data due to data modification. The LV memory manager is very intelligent, so it will perform the index operation first and then the replacement operation, thus reusing 4K memory, so the occupied data space is still 4K.

The functions of these two diagrams are exactly the same, but the data space memory usage is completely different. LV memory reuse first chooses the top-down approach.

The data type of the random number in the loop is DOBLE, 8 bytes, so the data flow is 8K, 1.2 plus the indicator operation data, a total of 24K,

In the figure below, in the ADD process, it first tries to select 1 for reuse, but 1 is needed in the multiplication input, so it cannot be reused, so 8K bytes are occupied at 3. What is puzzling is why it does not reuse the memory of 2, because it first selects 1 above. It can be seen that the LV memory manager is not omnipotent.

 

Since LV first chooses to reuse the top, the bytes in the above figure should be 8K+8K+8K=24K. Why does it use 16K? This is another principle. The top is a scalar, and the result of the operation is an array. Obviously, a scalar cannot be reused as an array. Therefore, it chooses the array output below to reuse. 8K+8K (indicator) = 16K

 As can be seen from the above figure, unconnected outputs do not occupy memory space, because there is no subsequent data that needs to flow for unconnected outputs, so LV does not allocate memory for them.

 The default values ​​in SUBVI also occupy a large amount of memory space, especially arrays and strings, which will maintain their default values ​​inside the VI and be saved on the disk along with the VI. Of course, setting default values ​​is very helpful for debugging the sub-VI. If the testing is completed and the default values ​​of the sub-VI are not needed, remember to clear them.

There are also some issues that mainly involve data type conversion, which will be analyzed in combination with data types.