Improving the Performance of Your

NI LabVIEW Applications

Improving Performance in
LabVIEW

Purpose of
Optimization

Profiling
Tools

Memory
Optimization

Optimization Cycle

Benchmark

Optimize

Evaluate performance
Identify problem areas

Improve efficiency
Improve speed

Why Should You Profile Your VIs?

The 80/20 rule of software performance

80 percent of the execution time is

spent in 20 percent of the code
Performance improvements are most
effective in the 20 percent
Guessing which 20 percent is difficult

Improving Performance in
LabVIEW

Purpose of
Optimization

Profiling
Tools

Memory
Optimization

Windows Task Manager

Gives user a rough idea of
whether memory or CPU is
the bottleneck
Can be helpful in
identifying memory leaks
ViewSelect Columns
allows you to add additional
stats

Perfmon
Allows you to monitor
Processors
Disk I/O
Network Tx/Rx
Memory/Paging
Access by typing
perfmon into the
Windows Run dialog

Benchmarking Code Execution

Timing Template (data dep) LabVIEW Shipping Example

Benchmarking Code Execution

Code

Analysis
Calibration
Benchmark Project LabVIEW Real-Time Shipping Example

VI Profiler
Timing and memory statistics for VIs
ToolsProfilePerformance and Memory

Demo VI Profiling

LabVIEW Desktop Execution Trace

Toolkit

Detailed
execution
traces
Thread and VI
information
Measurement
of execution
time

Multiple
Sessions

Threads, CPU
and Memory

VIs

Benchmarking Summary
OS Level
Task Manager, Perfmon

LabVIEW Level
VI Profiler, Benchmark VIs

VI Level
LabVIEW Desktop Execution Trace Toolkit

Improving Performance in
LabVIEW

Purpose of
Optimization

Profiling
Tools

Memory
Optimization

VI Components
Panel
Diagram
Code
Diagram compiled into machine code

Data
Control/indicator values
Default data
Block diagram constant data

VIs in Memory
When a VI is loaded into memory
We always load the data
We load the code if it matches our platform
(x86 Windows, x86 Linux, x86 Mac, PowerPC Mac)
We load the panel and diagram only if we need to
(for instance, we need to recompile the VI)

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

LabVIEW Terminology
Panel data is called Operate Data
Controls and indicators have their own copy of the
data, so that front panel editing of data does not
interfere with computations in the diagram

Diagram data is called Execution Data

Every wire represents a buffer of data

Transfer Data is used to copy between them

Avoids multithreading issues

Memory Performance
The following features affect the impact
memory allocation has on your application:
Wire Semantics and In Placeness
Type coercion
Passing values to subVIs
Shift registers
Front panel indicators

Wire Semantics
Every wire is a buffer
Branches typically create copies

Optimizations by LabVIEW
The theoretical 5 copies become 1 copy operation
Copy

Output is in place with input

The In Place Algorithm

Determines when a copy needs to be made
Weighs arrays and clusters higher than other
types

Algorithm runs before execution

Does not know the size of an array or cluster

Relies on the sequential aspects of the

program
Branches may require copies

Bottom Up
In-place information is propagated bottom up
Branched wire

Copy because
of increment

No copies required
Increments array in place

Showing Buffer Allocations

The In-Place Element Structure

Allows you to explicitly modify data in place

Types of Border Nodes

Array index/replace element

Array split/replace subarray
Unbundle/bundle
Waveform unbundle/bundle
Variant to/from G data
Simple in place relationship
Data value reference
read/write

Example of In Place Optimization

Operate on each element of an array of waveforms

Make the First SubVI In Place

changes into

SubVI 2 Is Made In Place

Changes into

SubVI 3 Is Made In Place

Changes into

Final Result: Dots Are Hidden

Type Coercion
Changing the data type of a wire to match
the required data type
Dots indicate automatic coercion
Requires a copy
Coercion Dot

Passing Values to SubVIs

SubVI does not always have to make a copy
Best when
Inputs are required
Inputs and outputs are not in structures
Inputs and outputs are in place

Passing Values to SubVIs

Parameters within structures cause
unnecessary copies

Move

Shift Registers
Single left input always in place with right
output
Even better when the body is in place
In Place

Always In Place

Building Arrays
There are a number of ways to build arrays
and some are better than others

Bad
Reallocates array memory on
every loop iteration
No compile time optimization

Building Arrays
There are a number of ways to build arrays
and some are better than others

Better
Memory allocated
at load time
Keep graphics
below the text
Values populated
in place
and to the right.

Building Arrays
There are a number of ways to build arrays
and some are better than others

Best
Memory preallocated
Indexing tunnel eliminates
need for copies

Build Array Ordering

Appending to the end of an array is much

more efficient than prepending to the
beginning
If you need to insert items at the beginning,
insert at the end instead and use a single
Reverse Array when finished

Demo Effects of Memory

Optimization

Improving Performance in
LabVIEW
Purpose of
Optimization

Profiling Tools

Memory
Optimization

Decrease memory usage, increase speed

80/20 Rule

Improving Performance in
LabVIEW
Purpose of
Optimization

Profiling Tools

Memory
Optimization

Windows Tools (Task Manager, perfmon)

VI Profiler
Real-Time Execution Trace Toolkit

Improving Performance in
LabVIEW
Purpose of
Optimization

Profiling Tools

Hide the dots

Take advantage of in placeness

Memory
Optimization

Next Steps
In LabVIEW
LabVIEW Help
On the Web
ni.com/multicore
ni.com/devzone

Next Steps
Visit ni.com/training
Identify your current expertise level and
desired level
Register for appropriate courses