LabVIEW
Use of sub-VIs to reduce block diagram size in top level VI
You can do some tests if you're really interested. A subVI call adds a few nanoseconds, but that can be removed if you make the function/SubVI Inline. Usually that's negligable, but as Always there's some cases in which those few extra ns's is what's needed.
Knowing about it though, can be quite good, as the suggestion then becomes to have a subVI that accepts an Array and does the looping internally instead of having a function inside a loop … i'll have to do some test to try out my own hypothesis. 🙂
/Y
@Bob_Schor wrote:
@NeilR wrote:
Although slightly unpopular I quite often use a stacked sequence as a main structure with typically initialisation, operation and shutdown frames.
When I first encountered the Stacked Sequence, I was simply appalled, particularly by what they did to wires traversing them. In one instance, I remember replacing them with a For Loop surrounding a Case Statement and using the Case as the "Frame Iterator" [I don't do that anymore, but I only had a year or two of LabVIEW under my belt]. Note that NI has removed them from the Structure Palette (I think they are still available, but Out of Sight, Out of Mind).
Keep reading Blume's book -- when you reach the end, do as I did (twice) -- wait a month, and read it again. Short of having an In House LabVIEW Guru to give you constant feedback, this may be the best "short-cut" to learning good LabVIEW Style, which directly translates (in my opinion) to better LabVIEW Code.
Bob Schor
As you said, Bob, the stacked sequence is so not recommended that NI has kept it only for backwards compatibility and has deleted it from the Structures palette. A state machine can replace all instances where you would be tempted to use a stacked sequence structure, but has the advantage that you can call any state from another. Plus, state machines are so easily scalable, it's ridiculous.
@Bob_Schor wrote:
The point Yamaeda was really making is that Call/Pass Variables/Return takes such a minute fraction of the CPU that unless you deliberately wrote a sub-VI that did a lot of "thrashing" of its input/output variables, you would be hard-pressed to be able to measure a Time Penalty, whereas not encapsulating code in sub-VIs will cost you far more time in coding, debugging, trying to understand a 4-screen Block Diagram with 140 wires running all over ... Your Sanity is worth a few nanoseconds!
Bob Schor
I was worried about the timing because I need to run a Data acquisition VI every 5 ms. As per Blume's book, it is better to go on making sub-VI's till they become cohesive. So for a really big application, that will mean a lot of sub-VIs.
But if each sub-VI is only taking a few nano-sec, then it will need a million sub-VIs to reach ms level of delay. So, yes, I'll opt for my sanity. 
I thought the stacked sequence comment would provoke an interesting response !
What I would say is that I pass no wires to or from any of the stacked frames. I get that.
It's simply a "fixed state machine" if you like that applies to pretty much all situations in the top-level VI.
Generally in frame 1 I do things like Reinit All to Default, hide the front panel - resize it to largest decoration (thanks OpenG !) and then fade in using graduated transparency ... mmmm nice ... plus store things like Tab terminals and the like.
Frame 2 is where the magic happens. ... and usually contains a state machine or event structure.
Frame 3 is usually no more than a front panel fade out and environment dependent shutdown.
I totally agree that the use of stacked frames can extend a wiring nightmare from 2 dimensions to 3. I would say though that judicious use of stacks by experienced developers can keep things very tidy, but if you're uncomfortable then stick to state machines.
@Yamaeda wrote:
You can do some tests if you're really interested. A subVI call adds a few nanoseconds, but that can be removed if you make the function/SubVI Inline. Usually that's negligable, but as Always there's some cases in which those few extra ns's is what's needed.
Knowing about it though, can be quite good, as the suggestion then becomes to have a subVI that accepts an Array and does the looping internally instead of having a function inside a loop … i'll have to do some test to try out my own hypothesis. 🙂
Unless you have a subVI that contains a minimum amount of code inside and you call it in a tight loop billions of times, you will be hard pressured to measure any increase in execution time for that subVI compared to having its code executed directly in the diagram. And for those cases you have the inline option.
If your subVI contains anything but non trivial code, its own execution time will be usually magnitudes higher than the overhead of calling it as subVI.
