defer panel update results in slower performance

[CoastalMaineBird]

Sequence Structures of any kind introduce overhead in comparison to direct data flow. This is most often very low (insignificant).

--- And therefore irrelevant.

Direct dataflow is not always possible without expanding the diagram to unmanageable dimensions.  I use stacked sequences most often as a diagram space-saving device.  Adding subVIs has its own time penalties, probably exceeding those of a sequence. And that's even more obfuscatory (is that a word?) that the sequence.

Please refer to the LV help for information about sequence structures and the difference between stacked and flat one. It's too much text to post it here....

--- I understand the difference pretty well. 

- Stacked sequence structures often lead to unreadable code; esp. the sequence locals are prone to stupid errors.

--- That's a gross generalization that I would disagree with. If I want to pass three items from frame 0 to frame 3 of a flat sequence, I have to either run three wires outside the structure from 0 to 3, or I have to run three wires thru frames 1 and 2.  Either one of those makes the code more unreadable, IMO. 

- Flat sequence structures maybe do not behave as expected: an output tunnel of a frame passes data as soon as the frame is finished. This can have unexpected results when using output tunnels from frames which are not the last one....

--- That I agree with.  It's a violation of the rules that every other structure uses: Data does not leave the structure until the entire structure finishes executing. They had to violate that rule to make it work.  But that's not an indictment of the stacked sequence.

- Both types of sequence structures often prevent the programmer to think about a good framework.

--- There are lots of things that CAN do that:  Local variables, for example.  Does that mean that local variables are "bad" and "should not be used"?  I don't think so - they have their place as well.

The code often gets messy and therefore unreadable and not maintanable.

--- Messy code comes from messy programmers. 

[Norbert_B]

---

CoastalMaineBird wrote: [...]

--- Messy code comes from messy programmers. [...]

---

I'd say this is a gross generalization 😉

I don't want to deny the purpose of sequence structures and variables in a general way; sure they have their places. But experience is that very often (imho way too often) these two "features" lead to messy code; even from programmers who, in general, "know better".

There are some other points i want to bring up a little which you posted:

1) Yes, subVIs do introduce overhead which is larger than a sequence. But honestly, most often this overhead is most welcome:

    a) Modularization: The algorithm can be easily reused in other applications. This is hard/impossible if the algorithm is "just a sequence frame of the application"

    b) I encountered only very, very, very few applications (propably less than 1 in over 5 years), where the overhead of the subVI is a "killer criteria". So this is no point i'd bring up as a negative point in regard     to subVIs 

2) You are correct about less wiring with stacked sequence locals. But the wire is the data, so using those variables are clouding the information: where does the data origin from? where does it go? It is always better to stick to direct wiring or using dedicated datastorages as Functional Globals (AEs) or Queues.

3) Sequence structures in general are hard to maintain. Just try to add a new feature somewhere in between which requires new data and interacts with "old" as well. I'd say: Have fun!

4) The flat sequence is not really a violation. Each frame can be seen as a single structure. The appearance of a "film reel" just shows: those structures are executed in a special order.

5)

---

CoastalMaineBird wrote:

[...]Does that mean that local variables are "bad" and "should not be used"? [...]

---

Yes, exactly. This statement is due to experience, not by default. The structure (variable/sequence) itself is not "bad" (i hate this expression in this case), but it is most often used in a "bad way" (better expression!) leading to confusion, frustration and statements like "LV is not capable to solve this". This is aweful.

Ok, you see, i start running in circles and insisting on the same things twice in a single post.......

Norbert 

[CoastalMaineBird]

I don't want to deny the purpose of sequence structures and variables in a general way.

I have a hard time telling that from your statement:  

Stacked sequence structures are not really good. Don't use them.

[K1200LT_rider]

The inherited LabVIEW code I have had to modify at my company has always had a lot of stacked sequences (sometimes nested 2 and 3 levels deep!) and lots of globals and locals - to the point of being ridiculous sometimes.  It's like the previous "programmers" were learning by the seat of their pants while creating real-world (important) app's for test stations for surveillance items that would eventually be bolted into various military vehicles.  Anyway, this kind of code is amazingly difficult to figure out what it's doing.  I have to restructure everything to get rid of all the stacked sequences and globals, as well as other changes to a point where it's at least semi-sane to deal with.  A handful of new subVIs usually result, also.  Even though I don't like stacked sequences, I can still go with Ben's use for them.  I can't remember ever seeing or hearing another good use for them.  I only use flat sequences occasionally, but I keep them as small and simple as possible when there is no other reasonably easy way of forcing sequence.  If I were teaching someone LabVIEW, I'd tell them to never use a stacked sequence unless there was a very unusually compelling reason to do so.  And even then, ask me about it before doing it.

- Brad

[maxwellb]

Looks like this thread got a little off-topic back then.

I'm running into a very similar problem now. I have a stacked sequence structure with that basically does the following

 1. Read from some (~5) shared variables.

 2. Pass the shared variable data to some (~15) local variables.

 2. Distribute the local variable data to a lot of front panel indicators (~150).

It runs at 5 Hz.

I know that I could do this better ways, but I can't change it right now. My resource usage is not hurting much, but out of curiosity, I added a defer front panel updates property node which gets a True before the sequence runs and a False from the last frame. My average CPU usage jumped from 17% to 28%.

Why would deferring front panel updates ever increase resource usage?

[maxwellb]

I should mention that I'm using LV 2010 SP1.

[CoastalMaineBird]

Why would deferring front panel updates ever increase resource usage?

Not sure if this is your trouble or not, but DEFER UPDATES actually does an FP update when you turn it ON, and then again when you turn it OFF. 

If you have FP things changing in both worlds (regular and deferred), then that could explain your increase.

[Alexander_Sobolev]

---

@maxwellb wrote:

I'm running into a very similar problem now. I have a stacked sequence structure with that basically does the following

 3. Distribute the local variable data to a lot of front panel indicators (~150).

---

Writing into 150 indicators in 1 frame? And they are not in clusters, arrays? Is it possible to see this diagram? 

[maxwellb]

I do not have anything changing on the FP outside of this stacked sequence. I also tried implemented the deferred updates with a parallel loop as shown below. Same results.

[maxwellb]

Unfortunately, Alexander, I think I'd be strongly discouraged from posting this code. Yes it is actually 150 separate numeric indicators, not clusters.