Fuzzy Wires and Constant Folding in LabVIEW

In an effort to make running code as efficient as possible, National Instruments has introduced several optimizations at the run-time level in NI LabVIEW software. Noticeable optimizations introduced to the functions palette in LabVIEW 8.5 include the In Place Element Structure and Swap Values primitives to give you more control over memory allocation in your software. 

Although less noticeable, another improvement in LabVIEW lets you see where the LabVIEW compiler automatically makes your code more efficient. For example, Show Buffer Allocations gives you insight into the compiler’s behavior when choosing a time to reuse memory that has been allocated to previous values, or when new buffers are created to hold parallel or newly created data. This exposure of low-level LabVIEW functionality helps you make your code as efficient as possible by statically taking advantage of the efficiencies of the compiler. 

What Is Constant Folding? 

Constant folding is the process of replacing obsolete code with functionally identical, but more efficient, code. Consider Figure 1a. This simple code snippet adds two block diagram constants and displays the output in a front panel indicator. Figure 1b shows a functionally identical code snippet; the block diagram constants in Figure 1a never change. There is no functional benefit in doing the mathematical addition. Irrespective of when you run the code, the front panel indicator always displays the same value. 

Rather than taking up precious computation cycles to perform these redundant calculations during run time, LabVIEW automatically identifies the obsolescence and replaces the code with a slim-lined version before it is run, resulting in more efficient operation. The Tools >> Options >> Block Diagram setting reveals a new option to LabVIEW, which is to see when constant folding occurs. Choosing this option causes elements that undergo constant folding to appear “fuzzy,” which explains the common LabVIEW community term “fuzzy wires.” It does not mean you need to update your video driver, just that the constant folding optimization is taking place. 

Figure 1. Constant folding occurs when LabVIEW replaces obsolete code with a constant that it represents.

Constant folding does not occur in only simple block diagram primitives. If the compiler determines that the functionality inside loop structures is obsolete, it folds that as well (see Figure 2a). The loop always runs the same number of times; the output is always the same, so there is no reason to run the loop. Note the gray stripes in the loop’s background, which indicate constant folding is occurring. Figure 2b shows a similar code snippet in which constant folding does not occur. The number of times the loop executes is not determined in this code snippet; it can vary through either a user interacting with the front panel or have different data fed to it if called as a subVI. LabVIEW cannot determine the output outside of the loop, so it cannot replace the structure with a constant and will run the loop the number of times as defined in the front panel numeric. 

Figure 2. LabVIEW can replace complete complex structures when the code it contains is determined obsolete.

Why Is Constant Folding Important? 

Compiler optimizations have been around almost as long as software engineering itself. As the functionality you expect from computers increases, these optimizations can make a real difference in what works well and what does not. PCs are getting faster (mostly through parallel operations) and memory is getting cheaper, but that does not mean you can ignore more efficient methods of programming. 

To make code run more efficiently, National Instruments has made significant investments in research and development so you don’t have to. With that said, you should never consider code optimization unimportant. LabVIEW is putting optimization knowledge in your hands. Exposing the occurrences of these optimizations helps you, as a developer, to better understand and affect your software performance. 

Figure 3. Other LabVIEW run-time optimizations include buffer reuse.

What Other Optimizations Does LabVIEW Offer? 

Some of the optimizations that have the most impact on the standard LabVIEW program include buffer reuse and inlining. Buffer reuse occurs when LabVIEW detects that the data space at an input of a function is the same size as the data space at the output of the function, and the input data is not used anywhere else. In this case, rather than destroy the input data buffer, create a new data buffer for the output data, and place the data in the new buffer, LabVIEW reuses the input buffer space by overwriting it with the output data. Some incorrectly refer to buffer allocations as copy dots, but the presence of a buffer allocation dot does not necessarily indicate that a new copy of the data is created. Most of the time this is true, but under some circumstances the presence of a buffer allocation dot can seem misleading. For example, instead of creating new memory copies of subarrays, LabVIEW often creates a reference to just the portion of interest of the input array. The reference uses a small amount of memory so a buffer is allocated to hold it, but that does not mean a new buffer is created to hold the array data that it refers to. 

Inlining occurs when a VI calls subVIs that do not require the functionality of the subVI to remain encapsulated. In these cases, the code of the subVI is essentially moved out of the subVI and in line with the code of the calling VI, functionally making the subVI code part of the caller. This technique saves memory and processing time because the boundary inefficiencies of the caller and subVI are not required, so they no longer exist. 

The LabVIEW compiler performs compile-time inlining, but you also can force inlining in the development environment by adding the line “inlineSubVIEnabled=TRUE” to your LabVIEW.ini file. Once you restart LabVIEW, a new item called Inline subVI appears in the right-click menu of subVIs on block diagrams (see Figure 4). Selecting this item moves the code from the subVI into the calling VI, effectively the reverse of “Create subVI.” This feature does not usually make for the most attractive code and removes several often important features of using subVIs – including modularity, encapsulation, and scalability – but it is a handy shortcut if you need to force visibility in the development environment.

Figure 4. The Development Environment subVI inlining forces subVI code into its caller VI.

Do These Optimizations Really Matter? 

Like many life questions, the answer is “it depends.” Obsolete calculations waste processor time and memory and can even cause your processor to lock up. Even if your system is not as mission-critical as some, it is always a good idea to be aware of the low-level optimizations that could mean the difference between a happy user experience and a nondeterministic functional nightmare. 

– Christopher G. Relf 

Christopher G. Relf is a Certified LabVIEW Architect; Certified Professional Instructor; LabVIEW Champion; and the Chief Software Architect at V I Engineering Inc., a Select National Instruments Alliance Partner. Christopher is also a freelance technical journalist and moderator for LabVIEW Advanced Virtual Architects. 

Get more information on this and other advanced LabVIEW topics.  

This article first appeared in the Q2 2008 issue of Instrumentation Newsletter.

4 ratings | 4.75 out of 5

Read in | Print

Reader Comments | Submit a comment »

Inlining
Chris, Thanks for the great discussion. I've been a bit slow coming up to speed on some of these issues, so I was glad to see your article. I'm still a bit confused about inlining. You say that the compiler does some of this at compile time. I'm curious what the circumstances are for when this is done. Also, would it make sense to have this as a right-click configuration option on sub-vis? Maybe within the Call Setup window. It might fit in as a distinct option there. Rather than loading with callers, loading with each call, or loading on the first call, you could also specify that it should be inlined. Having LV determine when this option should be enabled might be interesting... You couldn't very well inline a sub-vi that had an active front panel. Probably lots of other more subtle considerations as well. DaveT
- David Thomson, Original Code Consulting. dthomson@originalcode.com - Jul 2, 2008