Strategies for Improving VI Execution Speed

The more you allocate, deallocate, or move data in memory, the more memory the VI uses. Memory can also indirectly affect execution speed because allocating more space in memory leaves less memory for other operations, causing them to slow down if they reach the memory's capacity.

When creating a VI, consider the following guidelines:

• Use consistent data types and watch for coercion dots when passing data to subVIs.
• Avoid using hierarchical data types such as arrays of clusters containing large arrays or strings.
• Reduce the use of nested subVIs inside of other VIs, as these can cause an exponential increase in the number of VI clones needed to maintain separate data spaces for each call to a subVI.

Avoid the following, which can create additional and unnecessary copies of data:

• Repeatedly resizing data—Clearing space in memory or adding and removing data from memory creates overhead and can take time.
• Overusing duplicated array and string terminals—Creating more than one corresponding object on the diagram can increase memory usage.
• Unintentionally coercing data—Coercion dots appear on nodes when data types are coerced. Data type coercion can decrease execution speed and increase memory usage, especially when you use complex data types or large arrays because they can increase memory usage.
• Displaying large arrays and strings on panels—Displaying the smallest array or string on the panel will ensure that copies of data remain small. The larger the array or string, the larger the copy of contained data.

• Remove unnecessary panel objects and avoid adding objects to the panel that aren't necessary for controlling input to the diagram or observing output data.
• Avoid transparent and overlapped panel objects unless necessary.
• When using charts, reducing Chart History Length in the Configuration pane will set the maximum number of data points drawn to your chart.
• When using graphs and charts, turn off auto-scaling, axis labels, anti-aliased line drawing, and axis grids to prevent drawing more elements. A graph with fewer elements takes less time to redraw every time the graph updates.

Since all parallel loops share the same processor resources, consider the following practices to make sure other loops do not interrupt the timing or execution of your important tasks:

• Important Operations—Because you want this type of operation to execute as frequently as possible, do not add timing nodes inside the loop to delay its execution.
• Executions Dependent on Dequeue Element node—The Dequeue Element node can halt the execution of a loop until an element is ready in the queue. This node allows more important loops to use more of the processor's time.
• Low-Importance Operations—Because this type of operation is the least important, you can use a Wait node to run the operation less often and yield execution time to the other loops.

The following is an example of a recreated VI using the considerations:

1. The Read DAQ loop reads data from a DAQ device and sends the data to a queue. Do not add timing nodes because you want this type of operation to execute as frequently as possible.
2. The Write to File loop can execute more slowly as it is logging data points for later analysis. The execution of this loop can be dependent on elements being ready in the queue because it does not need to execute as frequently.
3. The Check Temperature loop displays temperature data to the user and uses a Wait node to run less often and yield execution time to the other loops because it is the least important.