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

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 RT Performance