Formatted -- Optimizing VI Performance

8/10/2019 Formatted -- Optimizing VI Performance

1/36


2/36

Optimizing VI Performance

Dan Hedges


3/36

Overview

Understanding and Locating Performance Problems Understanding areas in LabVIEW that affect performance

Memory copies

UI redraws

Library selection

Property Node usage

Thread friction

Reentrant VI usage


4/36

Steps to Improving Performance

1. Make your VI work2. Run the VI Performance Profiler

3. Improve performance of key areas


5/36

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


6/36

Profiling Demonstration

Select Tools>>Advanced>>Profile VIs


7/36

Common Causes of Performance Problems

Incorrect coding Bad algorithm

Improper library calls

Unnecessary repetition

Recalculating a value rather than storing it for reuse on each iteration

Incorrect timing

Too early

Too late


8/36

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


9/36


10/36

Execution Data, Continued

Functions that read can be scheduled to run beforefunctions that modify

LabVIEWs scheduling is good, not perfect


11/36

Building Arrays and Strings

Functions that tend to cause memory reallocation Build Array

Concatenate Strings


12/36

Bad Use of the Build Array Function


13/36

Better Use of the Build Array Function


14/36

Good Use of the Build Array Function


15/36

Best Use of the Build Array Function


16/36

Type Conversions

Make programming easier Explicit bullets

Implicit dots

Require extra time and memory Limit conversions by using consistent data types

Only limit conversions that are executed often


17/36

Avoid Coercion Dots


18/36

Avoid Coercion Dots

Results from profiling the previous two VIs:


19/36

Slow Libraries

The easy way is rarely the efficient way Higher level VIs do many things that may not berequired

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


20/36

Math Efficiency

LabVIEW compiler generates more efficient code inprimitives than chained operations

Math primitives with an array input are faster than

performing the array multiply using a loop

Is faster

than ->


21/36

UI Updating

Drawing to the screen is the most overlookedperformance bottleneck

Expensive math or driver calls are more obvious than

expensive drawing Like memory management, LabVIEW tries to optimize UI

drawing but it can not perform miracles


22/36

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


23/36

Panel and Diagram Data

Front panel controls and indicators need their own copy ofthe data to display, called operate data

This VI uses about 8 KB of data if the panel is open, andabout 4 KB otherwise

On multithreaded systems, an additional 4 KB of transferdata is used


24/36

When Do Controls Keep Copies of Data?

Controls and indicators keep operate data when thefront 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


25/36

When Do Controls Keep Copies of Data?

Local variables read from and write to the operate data Controls and indicators that have local variable

references also keep a copy of their operate data


26/36

UI Management

Only update indicators as often as you need More than 10 times per second is excessive

Understand indicator data copies

Data is copied from the wire to the transfer buffer each timeyou update the indicator

Data is then copied to the indicator on each update


27/36

Indicator Updating

If an indicator is placed in a loop, you should use atimed 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


28/36

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


29/36

Property Nodes

Chaining together properties Cause multiple thread swaps

Cause multiple UI updates

It is better to run the VI in the UI thread so it does not haveto swap threads on each property node

Property nodes in an un-throttled loop are bad


30/36

Defer Panel Updates

When performing multiple control property changes ona graph, use Defer Panel Updates

Disables UI refresh until the property changes are complete


31/36

Control References

There are performance tradeoffs to using controlreferences

Property nodes using control references have the same

performance issues as regular property nodes

The value property has the performance characteristics of a

Property Node, not a terminal


32/36

SubVI Calls

SubVI calls are relatively expensive 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 bereally expensive

However, calling a subVI does not inherently cause a

new memory copy


33/36

Interfacing to External Code

Look for red Call Library Nodes or Code InterfaceNodes

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


34/36

Reentrant VIs

Using reentrant VIs in two different casesAllows a subVI to preserve state between calls

Allows a subVI to be called in parallel

Understanding reentrant VIs is very important if youneed good performance


35/36

Summary

1. Make your VI work2. Run the VI Performance Profiler

3. Improve performance of key areas

Memory copies

UI redraws

Library selection

Property Node usage

Thread friction Reentrant VI usage


36/36

Additional Resources

LabVIEW Performance and Memory Management Note Refer to the NI Developer Zone at ni.com/zoneand enter AN114 in

the Search textbox

The Need for Speed,vol 7, number 4, and LabVIEW 6i

Performance Improvements, vol 8, number 1 Refer to the LabVIEW Technical Resource Web site at ltrpub.com

Formatted -- Optimizing VI Performance

Documents

Transcript of Formatted -- Optimizing VI Performance