1. “Optimize Your VI Performance” Dan Hedges National Instruments Web Event: 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

3. Steps to Improving Performance • Make your VI work • Run the VI Performance Profiler • Improve performance of key areas

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

5. Profiling Demonstration • Select Tools>>Advanced>>Profile VIs

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

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

8. Execution Data, Continued • Functions that read can be scheduled to run before functions that modify • LabVIEW’s scheduling is good, not perfect

9. Building Arrays and Strings Functions that tend to cause memory reallocation • Build Array • Concatenate Strings

10. Be Aware of Coercion Dots

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

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

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

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

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

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

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

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

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

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

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

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

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