General Performance Improvements

Although the LabVIEW Real-Time compiler produces code that generally executes very quickly, you should generally streamline code for time-critical applications. This document discusses factors that affect execution speed and suggests some programming techniques to help you obtain the best performance possible. Examine the following items to learn how to improve performance.

Flat VIs (SubVI Overhead)

When you call a subVI, there is a certain amount of overhead associated with the call. This overhead is fairly small (on the order of tens of microseconds), especially in comparison to I/O overhead and display overhead, which can range from milliseconds to tens of milliseconds. However, this overhead adds up. For example, if you call a subVI 10,000 times in a loop, this overhead might take up a significant amount of time. In this case, you might want to consider whether the loop can be embedded in the subVI. Another option you might consider is turning certain subVIs into subroutines (using the VI Setup Priority item). When a VI is marked as a subroutine, the execution system minimizes the overhead to call a subVI. There are a few trade-offs, however. Subroutines cannot display front panel data (G does not copy data from or to the front panel controls of subroutines), they cannot contain timing or dialog box functions, and they do not multitask with other VIs. Subroutines are short, frequently executed tasks and are generally most appropriate when used with VIs that do not require user interaction. Refer to Chapter 26, Understanding the G Execution System, in the G Programming Reference Manual for more information.

See Also:
G Programming Reference Manual

Debugging/Logging/Auto-handling of Menus Turned Off

To reduce memory requirements and to increase performance slightly, you can compile a VI after disabling various window options in the VI setup. The three options in particular are Allow Debugging, Enable Log/Printing at Completion, and Auto Handling of Menus at Launch.


When these options are disabled, the VI uses less memory, compiles more quickly, and performs better overall.

BIOS Settings for Networked LabVIEW Real-Time PXI Controllers

Another way to improve performance of LabVIEW Real-Time applications running on networked LabVIEW Real-Time PXI controllers is to disable USB hardware in the BIOS of the PXI controller. If your LabVIEW Real-Time application running on the PXI controller is experiencing too much jitter, it is possible you have the USB hardware enabled. You can reduce jitter in your LabVIEW Real-Time applications running on PXI controllers by making the following BIOS setting changes:

Integrated Peripherals ---> USB Keyboard = DISABLED

(PXI-8170 Controllers Only)
PnP/PCI Configuration ---> Assign IRQ for USB = DISABLED

Making these changes can reduce or even eliminate jitter spikes in your LabVIEW Real-Time application because these settings disable interrupts that are normally generated when USB devices are enabled in the BIOS.

Caching Effects

Most modern computers have various levels of memory, including RAM, Level 1 (L1) cache, and Level 2 (L2) cache. A cache is simply a supplemental high-speed mechanism for storage, which is generally faster than main memory (RAM). Composed of DRAM, main memory is commonly referred to as RAM and is separate from memory cache, which is generally made up of SRAM and consequently much faster. The purpose of a memory cache is to improve computer performance by storing the most commonly used instructions and data in SRAM. Because many applications often use the same instructions or data repetitively, a memory cache can improve performance by storing these instructions or data in the faster SRAM rather than DRAM.

Most modern computers are equipped with both an internal cache and an external cache. Internal cache (L1 cache) usually resides on the die of the processor, while external cache (L2 cache) can reside on the die near the processor or on the motherboard. L1 cache can typically hold around 16 to 32 KB of instructions and data, while L2 cache is generally much larger (~ 256 to 512 KB). The process of determining which instructions and data should reside in cache, and which should not, has been an ongoing optimization challenge for computer scientists and processor designers.

Memory caching is an important topic in LabVIEW Real-Time, because having a memory cache can speed up processes in some cases, but it can also affect determinism by inducing jitter. Caching can induce jitter, especially the first few times through a time-critical loop as the cache is getting sorted out. Furthermore, caching is important to consider because of non time-critical operations the user might execute during the sleep mode of a time-critical loop. If these non time-critical operations impact the cache differently each iteration of the time-critical loop, the application could suffer from jitter.

The effect cache has in speeding up an application is referred to as a caching effect, which can have a major impact on LabVIEW Real-Time applications. A large, inefficient VI might utilize a lot of RAM and not take full advantage of the memory cache, and will resultingly execute slower than a smaller, efficient VI that does the same thing but optimally utilizes the memory cache. Reducing the size of a VI and optimizing its memory usage can speed up a LabVIEW Real-Time application because less data and fewer instructions will be dumped into RAM. In fact, in some cases it might be worth investing extra time to optimize the subVIs in an application in an attempt to fit them into the cache. Better still, if a project is reasonably small, it could potentially run on the memory cache exclusively.

Mass Compile

Mass compiling a VI is another way to improve performance of a LabVIEW RT application. Although, in many cases, compiled LabVIEW code may not change after mass compiling it, a LabVIEW RT application will achieve optimal performance when mass compiled. Mass compiling a VI in LabVIEW RT not only compiles the top-level VI, but also recompiles and re-links all the subVIs and functions on the diagram window with the top level VI. This can sometimes lead to better performance.

Turning off Event Logging

In LabVIEW Real-Time 6i you can also turn off event logging on the PXI controller. To do this, you will need to modify the ni-rt.ini file. You can find this file under \national instruments\RT Images\LabVIEW\6.0.3. Add the following line to the file:
RTTarget.EventLogging.EnableAll=FALSE
Then ftp the file to your PXI controller's root directory.

Reader Comments | Submit a comment »