I try not to use sequence structures. But, occasionally I find it easier to put a few vi's in a sequence structure and wiring the ERROR IN and ERROR OUT through it instead of going through the process of making a subvi (i.e. editing icon, connecting wires, etc). I'm not sure what the big difference is ... not saying there ISN'T a difference ... between a sequence structure that holds the same information as a subvi.
For example, let's say I want to use the Get Date/Time in Seconds vi to display the start date/time for a test I'm running. So, I place this vi with an indicator inside a sequence structure. The only wires going in and out of the sequence structure are ERROR IN and ERROR OUT. (I'm sure there is another way to acquire this information, but I'm just trying to illustrate an example).
Or, let's say I make this same code (the Get Date/Time in Seconds vi and indicator) as it's own vi, with one input (ERROR IN) and two outputs (ERROR OUT and the indicator).
How does the sequence structure and subvi described above differ?
There will be a boundry around the sub.vi causing a insignifigant amount of overhead for the sub.vi call. UNLESS you inline the sub.vi at which point the compiled code will be identical since the compiler will take the inlined sub.vi and suck it into the caller's BD with a sequence frame around it behind the scenes (your view of the callers BD will not change)
The only other differences are: you can find the sub.vi on the functions palatte and drop it on any BD without all the Open caller you have it on then Copy-paste hassle and, you can View the VI documentation that you wrote and save the BD comments. The inlined sub.vi is worth the 3 minutes it'll take you to write this and edit properties.
An important difference is scalability and code maintenance.
When the code scales up, the stacked sequence structures will be a nightmare to deal with. If other people need to edit your code, you name may be used in vain.
If you are concerned with performance, I would follow Jeff's advice.
Philosophically I am opposed to using the error wires for anything other than error handling. Before you know it your entire VI is serialized. Unfortunately the alternative (sequence structure) is a bit unwieldy. If I were to write questions for the CLAD exam, this would be one: What is the result of this VI?
Just some food for thought to make sure you are timing what you think you are timing.
Ray already mentioned scalability. The very big bonus of having a SubVI, you change something and you are done. If you have several sequences, you need to search the primitve to make a change at every place. Consider using Get time/date string. Now your customer want's to have it displayed differently (maybe needing ms for a log file or not asking to display the year with two chars '11' instead of '2011' as he is sure your machine will be obsolete by 2100 -> I really got that told once).
Another very nice idea (just use OpenG for this) is to wrap the wait prim in an error structure. You won't want to wait a measurement cycle of some min just to get the error displayed why it didn't capture any data.
But there are certain use cases, a sequence is doing the job. Like fast benchmarking of code, dll calls or a simple Init->Do->Shutdown machine that doesn't justify a state-machine. And yes, fixing race contidtions of globals in your old code before you learned about action engines.
What, we are doing dataflow puzzles now? 😄
So, what is the approximate output of this VI?
Unlike stacked sequences, flat sequences should not be considered a single structure, but a sequence of structures containing at least one common data dependency. Here is a code equivalent of Darin's example that makes the result more obvious.
These would make good trivia questions during NI week