Improving the Performance of Your NI LabVIEW Applications
Improving Performance in LabVIEW Purpose of Profiling Memory Optimization Tools Optimization
Optimization Cycle Benchmark Evaluate performance Identify problem areas Optimize 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 Profiling Memory Optimization Tools Optimization
Windows Task Manager Gives user a rough idea of whether memory or CPU is the bottleneck Can be helpful in identifying memory leaks View»Select 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 Calibration Analysis Benchmark Project LabVIEW Real-Time Shipping Example
VI Profiler Timing and memory statistics for VIs Tools»Profile»Performance 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 Profiling Memory Optimization Tools Optimization
Panel Diagram Code VI Components 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
Every wire is a buffer Wire Semantics 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 Keep graphics at load time Values populated below the text 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 Memory Optimization Hide the dots Take advantage of in placeness
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