The short answer is the fastest way to call a VI from a VI is with a direct call. Any other way of doing it is somehow wrapping this mechanism which means added overhead. If you want to hear some of the details, then you can read on.
When a caller VI loads, it is "patched" with its subVIs. This means it holds onto a pointer that it can use to efficiently call that VI. The caller also allocates a parameter list for each call. When the call executes, the only thing the caller has to do is fill out this parameter list with the locations of its data and pass the pointer to this table to the subVI's code.
When you call a VI that is built into a DLL, the call library node must first put all the parameters into the form expected by the DLL calling convention. This is different than LabVIEW's parameter list approach and typically means putting each parameter on the CPU's stack. The exported function in the LabVIEW built DLL, must first get a connection to the VI to execute. It accomplishes this by getting a VI reference from a cache of VI references created when the DLL loaded. Each VI reference has a parameter list which must be filled in the parameters for this call. It can then call the code. When the code is complete, there may be additional work to put any outputs into the form expected by the caller. The VI reference must then be returned to the cache.
So there will be more parameter manipulation when calling through a DLL and a couple of accesses to a cache that can cause overhead and additional jitter with parallel calls. Even a call through a strict VI reference a would be faster. With that you are in direct control of the VI reference so no cache is involved and the call puts the parameters directly into a parameter list the subVI expects so there is less manipulation there.
There are also several other limitations introduced by calling a VI through a DLL.
- If you pass data to the DLL that contains handles, then you must make sure that the DLL is only ever called from VIs in the same version of LabVIEW. If you don't do this, then you will be passing handles allocated in one memory manger to a different instance and LabVIEW will abort.
- If you avoid passing data that contains handles, then LabVIEW will have to make copies of any strings or arrays that are passed to the DLL, further hindering performance.
- Preallocated reentrancy is not available through DLLs. This is the kind of reentrancy that allows the subVI to maintain state specific to each caller. When called through a DLL, we have no idea where we got called from so we can't give you back a specific instance. Each cached VI reference will have a specific VI instance but you don't know which one you will get. In essence this makes all reentrant VIs in DLLs act like shared reentrant. (This could explain why it didn't seem like your uninitialized shift register was working.)
Hopefully all this doesn't scare you off using LabVIEW to build DLLs. When you need to communicate to other software, it is the way to go and all these steps are necessary to cross that boundary. But if you are already in LabVIEW this is not an ideal replacement for directly calling a subVI.
