1. “Optimize Your VI Performance”
National Instruments Web Event:
“Optimize Your VI Performance”
Dan Hedges
Centra Environment Tools:
Ask Questions – Click on the ‘Text Chat’ button
“Yes” Response – Click on the green check mark
“No” Response – Click on the red ‘X’ mark
                                      

2. Overview Locating Performance Problems
Understanding areas in LabVIEW that affect performance
Memory copies
UI redraws
Library selection
Property Node usage
Thread friction
Reentrant VI usage
Historically, the training courses and seminars given on how to monitor and increase VI performance emphasized memory usage in your VI. This seminar addresses other issues that can help or hinder performance of your VI. These issues can be even more important than your data manipulation.

3. Steps to Improving Performance
Make your VI work
Run the VI Performance Profiler
Improve performance of key areas
It is important not to spend too many resources optimizing the performance of areas of an application that rarely execute. Therefore, do not optimize all your code as you write it. First, create a working version, then profile and optimize it as necessary.

4. Why Should You Profile Your VIs?
The 80/20 rule of software performance
80% of the execution time is spent in 20% of the code
Performance improvements are most effective in the 20%
Guessing which 20% is difficult
Certain parts of your code use more execution time than others. There is very little benefit to optimizing code outside of the most common 20%. The trouble is that even the most experienced programmers cannot always predict what code will fall in that 20%. Therefore, it is important to use a profiling tool.

5. Profiling Demonstration
Select Tools>>Advanced>>Profile VIs
Select Tools>>Advanced>>Profile VIs to access the Profile window. Load the following example: examples\apps\demos.llb\Signal Generation and Processing.vi. Hit Start in the Profile window. Run the VI. Stop the VI. Hit Stop in the Profile window.

6. Memory Management
The most common and mysterious reason for poor performance of VIs
LabVIEW handles memory management automatically
You do not need to code when to allocate or deallocate memory
You have less control over when memory operations occur
In conventional C, C++, or Pascal programming, causes of many bugs and performance bottlenecks include memory allocation, reallocation and deallocation. In C, for example, you explicitly allocate memory (using the malloc() function), and have to remember to deallocate it when you are through using it. There are no bounds checking when you write to this memory, so you have to add your own tests to make sure you do not corrupt memory.
LabVIEW takes care of most of these details. The memory allocation still happens; it is just not explicit on the LabVIEW diagram.

7. Execution Data Diagram data is called execute data
LabVIEW tries to minimize the number of data buffers needed
Functions that just read the data do not need to copy it
This diagram uses about 4K of data total
Because the wire containing a 4K buffer branches into three, three buffers appear to exist. But because the three Index Array functions share the same input buffer, only one copy of the array needs to exist.

8. Execution Data, Continued
Functions that read can be scheduled to run before functions that modify
LabVIEW’s scheduling is good, not perfect
Because LabVIEW decides the order of execution of functions that have no data dependency, LabVIEW orders the execution to minimize the usage of memory.
The output array for the Replace Element 0 node seems like it would need to be separate from the input array buffer, but it is possible for a replace function to reuse the same buffer.
In this case, there is an Index Element function that needs to work off of the input buffer. If the Replace Element function executes first, and it reuses the input buffer, the Index Element returns an incorrect result. So in this case, LabVIEW will try to execute the Index Element function before the Replace Element function. If it cannot, Replace Element will not reuse its input buffer.
If the Replace Element function executes first, this diagram takes 8K of data. If the Index Element function executes first, the diagram takes 4K, so LabVIEW chooses to have the Index Element function execute first.

9. Building Arrays and Strings
Functions that tend to cause memory reallocation
Build Array
Concatenate Strings
Memory reallocation is costly when done too often. Therefore, you should limit these types of functions in areas of your code that execute repeatedly.

10. Be Aware of Coercion Dots
One minor change to a diagram can significantly affect memory usage. In the first example, one 80 KB buffer is used for the entire execution data, and another for the operate date for the array.
The following explains how memory is allocated on a PC for the second example:
One 80 KB buffer for the array output from the For Loop
One 100 KB buffer for the Adds extended output
One 80 KB buffer for the outputs coercion dot
One 80 KB buffer for the operate data of the array
Other platforms differ in the size of the extended output of the Add function.

11. Slow Libraries The easy way is rarely the efficient way
Higher level VIs do many things that may not be required
DAQ Easy I/O performs reconfiguration on each call
File primitives
Write characters to file will perform many operations
Open file, Seek file, Write block of characters, Close file
Can be 70 times slower than the write primitive alone
Neither are bad to use until you put them in a tight loop
LabVIEW programmers have a wide range of programming experience, so LabVIEW provides multiple ways to perform the same function.
For many operations, there is an easy way and an advanced way. However, the easy VIs may perform extra work unnecessary for the operation. This does not mean you should avoid using the easy VIs. However, if you are using an easy VI in the crucial part of your program, you may improve execution speed by using the advanced VIs. The key is to understand what unnecessary extra work the easy VIs do.

12. UI Thread Front panel updates occur in the UI thread
Execution takes place in other threads
Shared data must be protected, so LabVIEW creates an extra copy, called a transfer buffer
Front panel updates happen in the UI Thread. In multithreaded systems, execution takes place in other threads. But data shared between multiple threads must be protected from access collisions inside a transfer data buffer.
For example, to copy data from the executing diagram to a front panel indicator, the diagram must first make a new copy of the data in the transfer buffer. Then, the indicator copies the data into its own storage for display.

13. Panel and Diagram Data
Front panel controls and indicators need their own copy of the data to display, called “operate data”
This VI uses about 8 KB of data if the panel is open, and about 4 KB otherwise
On multithreaded systems, an additional 4 KB of “transfer data” is used
The block diagram of this VI needs a copy of the array, which takes up 4 KB (1,000 signed int32s, at 4 KB each). If the panel is open, it needs to keep its own copy of the array. Additionally, on multithreaded systems, a buffer of transfer data must be allocated, to allow data to be sent safely and quickly from the block diagram and the execution thread to the front panel and the user interface thread.
Do not worry about how much memory the scalar values take up. The 1000 occupies 4 KB, and the wire inside the loop represents 4 KB. Because these sizes are small in comparison to the size of the array, they are not usually counted.

14. When Do Controls Keep Copies of Data?
Controls and indicators keep “operate data” when the front panel is in memory
The front panel is kept in memory in the following situations:
The front panel is open
The VI has not been saved
The block diagram uses property nodes
Keep the front panel in memory when a front panel is open or has unsaved changes.
Many control properties, such as colors and numeric formatting, operate on data structures that exist in the front panel memory.
To print, you need the panel in memory. So data-printing, where the panel is printed after each execution of the VI, keeps the panel constantly loaded. Therefore, you can avoid loading and disposing the panel during data-printing.

15. Indicator Updating
If an indicator is placed in a loop, you should use a timed loop or throttle the update rate
Indicators can be updated at the expiration of a timer after a particular number of iterations
SubVI indicators should not be placed into a loop
To reiterate the previous slide, do not update the UI as quickly as possible, rather throttle the UI update rates.
A sub-VI has no user interface at all. Therefore, only update the indicators once to provide output values for the connector pane.

16. Property Node Effect on Performance
Control and Indicator Property nodes are slow
Control properties require a thread swap to the UI thread to execute
Property Nodes can not run in parallel
Many will force UI updates on completion of that node
Most LabVIEW programs that allow user interaction use property nodes to modify or read attributes of UI elements. Understanding the performance characteristics of these property nodes is important because they can slow down execution. The fact that property nodes swap to the UI Thread is even more important because the UI Thread is serialized. Multiple property nodes cannot run in parallel even if the diagram is written to allow parallelism. Finally, most property nodes will force a redraw of the control. This is significant for any control with a long redraw time like a graph.

17. Property Nodes Chaining together properties
Cause multiple thread swaps (not in 6.1 or later)
Cause multiple UI updates
It is better to run the VI in the UI thread so it does not have to swap threads on each property node
Property nodes in an un-throttled loop are bad
Typically, your program will not use just one property node, it will use many chained together. If this is the case, it is better to run the VI containing the property nodes in the UI thread. That way, there will be one thread swap when the subVI is called and one swap when the subVI exits rather than having two swaps for each property node.
As with indicators, do not run code containing property nodes as fast as possible. Updating a control faster than 10 times per second may cause you to spend all of your time updating the control rather than getting any real work done in other loops.

18. Defer Panel Updates
When performing multiple control property changes on a graph, use “Defer Panel Updates”
Disables UI refresh until the property changes are complete
You also can cut down on the impact of the control redraw. Defer Panel Updates Property is a property of Panel. To create a property node, select it on the Functions>>Application Control palette and place it on the block diagram. Right-click the node and select SelectClass>>viserver>>Generic>>G Object>>Panel. Then click the white area of the property node and select Defer Panel Updates. To use this node, set Defer Panel Updates to TRUE, perform all of your property node activity, then set Defer Panel Updates to FALSE.
This property helps when manipulating controls that draw slowly, like graphs.

19. SubVI Calls There is an expense incurred when calling a SubVI
Use subroutine priority if you have determined that a subVI is the hot spot and the subVI is called rapidly
Calling a subVI in a different execution system can be really expensive
However, calling a subVI does not inherently cause a new memory copy
Setting a subVI at subroutine priority greatly reduces the overhead of calling it, but there are costs. For example, the VI can no longer be debugged, and asynchronous operations should never be used. For example, you would never put file I/O operations inside a subroutine VI. Subroutine VIs allow you to avoid duplicating very small, common calculations throughout your applications, and allow you to abstract them into subVI’s without a noticable change in performance. If a significant amount of time might be spent inside your subVI, then any benefit of setting its priority to subroutine would become negligible.
Think of a subVI’s execution system as being its thread. Ordinarily, you would want to call a subVI in the same thread as the caller. But if you want different asynchronous operations to execute in parallel without blocking each other, you should put them in different execution systems.
To reiterate, this is only something you should worry about if your subVI call is in the hot spot. Do not simply change all of your VIs to subroutine priority in the hopes of getting better performance. Analyze your system and then make this change.
Shown Example:
BenchThreadSwap.vi

20. Interfacing to External Code
Look for “red” Call Library Nodes or Code Interface Nodes
Red nodes cause thread-swap every time they execute, yellow do not
Active X controls
Automation servers created via Automation Open can be called without swaps (if the server supports it)
Controls always are called with thread swaps
Interfacing external code is the most common mistake made when calling external code. By default, the Call Library Node will be red to keep new users from having thread-safety problems when calling external DLLs. However, this is a big performance issue. If your DLL is thread-safe, make sure you set the Call Library Function Node to be reentrant rather than Run in UI Thread.
ActiveX controls have similar issues. If you are calling a property or invoke node on an ActiveX control that was dropped on the front panel, there will always be a thread swap on each node. If instead you are calling the ActiveX control using a refnum created by the Automation Open node, then there may not be a thread swap. The only way to know is to ask the provider of the Active X control whether the control supports free threaded execution.

21. Reentrant VIs Using reentrant VIs in two different cases
Allows a subVI to preserve state between calls
Allows a subVI to be called in parallel
Understanding reentrant VIs is very important if you need good performance
Reentrant VIs have two different uses. For performance, it is important to understand that a VI must be marked as reentrant so that you can call it from two spots simultaneously. This functionality is especially important for VIs which may not be 100% CPU bound.
Shown Example:
ReentrancyTest2.vi

22. Summary Make your VI work Run the VI Performance Profiler
Improve performance of key areas
Memory copies
UI redraws
Library selection
Property Node usage
Thread friction
Reentrant VI usage
Remember to always fine-tune a working system where possible, as opposed to designing for performance. When the system is working, use the profiler to pinpoint areas that need improvement, and then use the tips outlined here to optimize them.

23. Visit ni.com/info and enter wevi03
Questions?
For more information:
Visit ni.com/info and enter wevi03 Or
Call (800)