Downsides to relying on flat sequences?

[GV_KawaiiDesu]

I feel like adding flat sequences often can be a good way to make sure the program runs in the order someone intends to run it. Are there any downsides on relying on flat sequences too much? (asking as a general question)

Sorry if this is vague, I'm more used to other traditional languages where it operates based on what is written first. Flat sequences seem like a really easy way to structure a program.

[RavensFan]

There is no easy way to break out of them early if you want to in the middle of its execution.

[JÞB]

That is a common issue when moving to a dataflow language like LabVIEW.  To enforce order of execution all you need is a wire.  If you have a wire you do not need a sequence structure and wires a easy to find.

The Downside of the sequence frames is that they DO introduce extra overhead in the code.  Stuff like synchronization boundaries (to make sure all inputs / outputs are ready to start or end a frame ) and Debugging hooks (you can probe the wire or place a breakpoints on either side of a tunnel).  Usually that's not a large performance hit but, its a practice that leads to sloppy coding practices.  After you work with LabVIEW for a while those old BDs will begin to embarrass you (Trust me OK?)

[billko · Accepted solution]

Repeat this mantra (found here😞

"A node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."

If you take this rule VERY STRICTLY and apply it to your code, you will be able to determine the order of execution yourself 99.9% of the time without using a sequence structure.  (And even the 0.1 % of the time you "can't", a dataflow purist will tell you it's only "inconvenient" and not "impossible" to enforce without a sequence structure.)  Just as importantly, you can determine what's NOT important to execution order.  The latter is very difficult, if not impossible, to do using a sequence structure.

Take the following:

Terminal B in the second frame must wait for the first frame to complete before it can be read.  Why force LabVIEW to read it then, when it could have read it at a time that was more efficient for it to read?  It's like trying to tell an operating system what order the threads are supposed to run.  In the vast majority of cases, it's simply more efficient to let the operating system take care of that kind of stuff.

[billko]

By the way, this was a GREAT QUESTION to ask!

[JÞB]

---

@billko wrote:

Repeat this mantra (found here😞

"A node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."

Take the following:

Terminal B in the second frame must wait for the first frame to complete before it can be read.  Why force LabVIEW to read it then, when it could have read it at a time that was more efficient for it to read?  It's like trying to tell an operating system what order the threads are supposed to run.  In the vast majority of cases, it's simply more efficient to let the operating system take care of that kind of stuff.

---

And that is the point behind the Wired Terminals not on Root BD VIA Test.

See the Clearing up the mud nugget  And the point I made earlier in this thread.

A breakpoint could be inserted and the user could CHANGE the VALUE in control B after Control A was read.

[GV_KawaiiDesu]

thanks for the help everyone! Once I get better I'm sure I won't use it much, there are just a couple parts in my program that I was confused about (I'll reevelauate if I really need the flat sequence).