1. Use Inlining
2. Use Static Dispatch for objects
3. Use global variables
4. Remove anything that's not REALLY needed

Other, not-so-big improvements (might or might not help):

• Disable “Allow Debugging” in VI properties
• Restart the whole system
• Allowing implicit type casts

• Most library types do not load their member VIs into memory.
• Classes and XControls are the only two types of libraries that load their member VIs.
• All library types do load their nested libraries, though.

LabVIEW uses the Read Link Info application method to harvest the linker graph info (know what to list in dependencies) without loading the files' contents into memory.

When dynamically launching cloneable instances, the shared vs. preallocated reentrancy setting doesn't matter. There's nothing to preallocate (due to the fact that the VI in question is never executing as a static subVI call), so a shared clone pool will always be used.

A reentrant VI with uninitialized shift registers (or feedback nodes, or any stateful data store) may have issues where a clone that goes idle is reused from the clone pool on a subsequent launch of the VI.

The 'preallocated' setting only affects static subVI calls of reentrant VIs. It means nothing for dynamically launched clones (like DQMH or AF).

There's always a pool, since LabVIEW doesn't know if you'll ever launch clones dynamically while the code is running. The VI setting just defines whether or not LabVIEW traverses the VI hierarchy to be able to find static sources to pre-allocate or not. Also, LabVIEW has some heuristics for optimizing memory manager hits so that it's not allocating 1 at a time, but rather groups of clones for the pool.

• NI: Memory Management for Large Data Sets

• Memory to put an Array in a Cluster

See Performance Monitoring

See RT Performance