Optimizing VI Performance

Dan Hedges

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

Steps to Improving Performance

1. Make your VI work
2. Run the VI Performance Profiler
3. Improve performance of key areas

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

Profiling Demonstration
Select Tools>>Advanced>>Profile VIs

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

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

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

Execution Data, Continued

Functions that read can be scheduled to run before
functions that modify
LabVIEWs scheduling is good, not perfect

Building Arrays and Strings

Functions that tend to cause memory reallocation
Build Array
Concatenate Strings

Bad Use of the Build Array Function

Better Use of the Build Array Function

Good Use of the Build Array Function

Best Use of the Build Array Function

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

Avoid Coercion Dots

Avoid Coercion Dots

Results from profiling the previous two VIs:

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

Math Efficiency
LabVIEW compiler generates more efficient code in
primitives than chained operations
Math primitives with an array input are faster than
performing the array multiply using a loop

Is faster
than ->

UI Updating
Drawing to the screen is the most overlooked
performance 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

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

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

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

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

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 time
you update the indicator
Data is then copied to the indicator on each update

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

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

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 have
to swap threads on each property node

Property nodes in an un-throttled loop are bad

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

Control References
There are performance tradeoffs to using control
references
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

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 be

really expensive
However, calling a subVI does not inherently cause a
new memory copy

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

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

Summary
1. Make your VI work
2. 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

Additional Resources
LabVIEW Performance and Memory Management Note
Refer to the NI Developer Zone at ni.com/zone and 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