Dev Days Performance
and Memory Management
Adam Kemp
Staff Software Engineer
LabVIEW Compiler Team
Goals
Understand the LabVIEW Execution
System
Learn to improve performance by:
Reducing data copies
Reducing overall memory usage
Understand VI Execution Properties
The LabVIEW Execution
System
The execution system is the part of
LabVIEW which is responsible for
actually running your code
Enables automatic parallelism
Unique to LabVIEW
Other languages require manual thread
management
The LabVIEW Execution
System
Works like a thread pool
A queue of jobs
A set of threads pulling jobs off the queue
Jobs (queue elements) are pieces of VI code to
execute
One queue per execution system
UI
Standard
Instrument I/O
Data Acquisition
Other 1
Other 2
Timed loops
LabVIEW Execution System
Each execution system has multiple
threads
Exception: UI has only one thread
LabVIEW Execution System
Clump 0
LabVIEW Clumping
ClumpAlgorithm
1
Clump 0
Clump 2
LabVIEW Clumping
Algorithm
Clump 1
Clump 0
Start of diagram:
Reads controls, then
schedules Clumps 1
and 2
Then sleeps...
Top For Loop
Indicator is
updated
Clump 0
Scheduled
Sleep...
Clump 0 Sleeping
Clump 2
Bottom For Loop
Indicator is
updated
Clump 0
Scheduled
Sleep...
Clump 1 Sleeping
Completion of
diagram:
Divide nodes, display
of
indicators, then VI
exit.
Clump 2 Sleeping
Going to sleep
When a node goes to sleep it puts itself on a
wait queue and then returns to the execution
system
E.g., Queues, SubVI calls, debugging, etc.
When it is done waiting it is taken off the wait
queue and put back on the execution queue
Sometimes VIs will yield execution by stopping
their execution and going back on the queue
E.g., While loops
Queue elements track progress so they can pick
up where they left off
Preferred Execution Systems
Some nodes must run in UI thread
Each VI can specify a preferred
execution system
Default is Same as caller
Switching Execution
Systems
Happens when code needs to run in a different
execution system than the caller or previous code
Most common with UI code
Switching execution systems can cause
performance problems
Requires going to sleep and then waking up on another
execution system thread
Switching back takes just as long
Can sometimes set Preferred Execution System to
avoid extra switches
Avoid unnecessary UI code
Priorities
SubVI priorities affect the priority of the queue
elements for that VI within an execution
system
Higher priority queue elements are pulled off
first
The priority setting does not affect the priority
of the execution system thread itself
The OS may preempt the whole thread to run the
thread for another execution system (or other
process)
Use Timed Loops to control priority more reliably
Subroutine Priority
Not a real priority
Reduces execution system overhead for very
commonly called code
Forces the whole VI to be in a single clump
Prevents the VI from ever going to sleep
No calls which may sleep (like queue operations)
No switching execution systems
Can only call other subroutine VIs
No parallelism
Can be set to Skip Subroutine Call If Busy
Usually not recommended
Inline VIs
Preferred replacement for Subroutine Priority
Entire block diagram is inserted into caller when
the caller is compiled
Zero call overhead
Can still contain parallelism
Allows for more compiler optimizations
Limitations:
No front panel access
Not all nodes allowed
Forces callers to recompile every time the SubVI is
modified
Wire Semantics
Every wire is a buffer
Branches create copies
Optimizations by LabVIEW
The theoretical 5 copies become 1 copy
operation.
Copy
Output is inplace with input
The In Place Algorithm
Determines when a copy needs to be
made
Weights arrays and clusters higher than
other types
Algorithm runs before execution
Does not know the size of an array or string
Relies on the sequential aspects of the
program
Branches might require copies
Bottom Up
In place information is propagated
bottom up through the call
hierarchy
Branched wire
Copy because
of increment
No copies required
Increments array in place
Showing Buffer Allocations
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
In Place Element Structure
Nodes
Seven border node types:
Array index/replace
Array split/replace subarrays
Unbundle/Bundle cluster
Unbundle/Bundle waveform
Variant to/from element
In Place In/out border node
Data Value Reference Read/Write
Right-click left or right border to add nodes
Panel Data or Operate
Buffers
Controls and
indicators have
their own copy of
the data
Memory is not
needed if the front
panel is not in
memory
Default data
increases memory
usage
Transfer Buffers
Copy
Copy
Transfer Buffers
protect data transfer
between Operate and
Execution Buffers
Only updated if front
panel is in memory
Local and Global Variables
Local variables update the data
transfer buffer.
Reading a local or global variable
always causes a data copy
Use wires to transfer data when
possible
Local Variables vs. VI Server Property
Node
Local Variables
Can run in any thread
Copies to/from transfer buffer
Writes cause second copy into operate buffer if front panel is
in memory (avoid this if possible)
Use when speed is important
Property Nodes
Must run in UI thread
Copies to/from operate buffer
Writes cause second copy into transfer buffer
Force front panel in memory
Use when synchronous display is necessary
Avoid both if possible
Data by Reference
Manipulate references to the data instead
of the data itself
Data
Reference
Data Copy
Reference
Data Copy
Reference
Traditional dataflow: branches
may create copies
By reference: points to
memory location
Data Value References
Act as references to data rather than
full data itself
Can protect access to data
Memory Reallocation
Preallocate an
array if you:
Conditionally
add values to
an array
Can determine
an upper limit
on the array
size
Conditional Indicators
An indicator inside a Case structure
or For Loop
Prevents LabVIEW from reusing data
buffers
Reentrancy and Dataspaces
Non-reentrant
One dataspace shared by every call
Only one call can execute at a time
Lower memory usage
Can save state (e.g., for LV2-style globals)
Standard reentrancy, aka Preallocate clones:
Every call has its own dataspace
Calls never have to wait
Pooled reentrancy, aka Share clones
Added in LabVIEW 8.5
Each call pulls a dataspace from a shared pool
New dataspaces are allocated dynamically if needed
Calls never have to wait (except possibly to allocate a new dataspace)
Required for recursion
LabVIEW Cleanup
LabVIEW cleans up many references
when the owning VI goes idle and others
when the process closes
Manually close references to avoid
undesirable memory growth, particularly
for long-running applications.
Memory Usage of the User Interface
Every control on the UI requires memory
in order to store the data structure
At run time, Control and Indicator data is
additional copy of block diagram data
Default data for controls may contribute
to unnecessary memory usage
SubVI UIs generally do not contribute to
memory usage
Tips for reducing memory
usage
Operate on data in place
Do not overuse reentrant settings
Close references to avoid leaks
Avoid operations which require the front panel to
be in memory
Ex: Control references
Save the VI and close the front panel before running
Avoid large default data in arrays, graphs, etc.
Only display information on the front panel when
necessary
Request Deallocation Primitive
Memory Fragmentation
1.6 GB
0.4 GB
Report
ed
0.34
GB
0.16 GB
0.42 GB
0.38
GB
0.3 GB
Actual
0.1 GB
0.16 GB
0.14 GB
Used
Available
General Benchmarking tips
Disable debugging
Save all
Close all unnecessary front panels
Questions
