The following are several frequently asked questions about subVIs.
A VI is described as reentrant when LabVIEW creates a separate data space for each instance of the VI. This allows multiple independent calls to the subVI to run in parallel. This also is useful when you need each instance of the VI to keep track of their individual states. Use Functional Globals to accomplish the opposite�multiple instances of a VI that all save their state in one location. You cannot make Functional Globals into reentrant VIs. By default, VIs are not reentrant and the execution system will not run multiple calls to the same subVI simultaneously. If you try to call a subVI that is not reentrant from more than one place, one call runs and the other call waits for the first to finish before running.
You can use the execution system of a subVI to cause a subVI to run in a different thread. National Instruments recommends that you use the same as caller default execution system for most VIs. If you do not use the default execution system for subVIs that frequently run, an increased number of thread swaps can hurt performance.
If you pass data to multiple locations, all of which read the data without modifying it, LabVIEW does not make a copy of the data. Instead, LabVIEW simply hands each caller a reference to the existing data. To generate a copy of the data, use the Always Copy function.
VIs that you set for Subroutine priority do not share execution time with other VIs. Use the Subroutine priority level in situations in which you want to minimize the overhead in a subVI that performs simple computations. However, there are some trade-offs. Subroutines cannot display front panel data, call timing or dialog box functions, allow debugging or automatic error-handling, or multitask with other VIs. Subroutines are generally most appropriate for VIs that do not require user interaction and are short, frequently executed tasks.
If a high priority VI calls a lower priority subVI, that subVI inherits the highest priority of any calling VI, even if the calling VI is not running.
Large block diagrams are hard to read and maintain. Identifying commonly reusable segments of code and replacing these segments with a subVI saves space and simplifies future updates to the code because you will have to edit the subVI only once, instead of each individual instance. Also, if you break the VI into subVIs, the code for the top-level VI is smaller, and the code and data of the subVIs reside in memory. In some cases, you might see lower run-time memory usage.