defer panel update results in slower performance

[Norbert_B]

Adam,

since you are in a single loop, the recommended way to store data are "shift registers" which can be seen as "variables". Another way is using Functional Global Variabels (aka Action Engine).

When working with charts, you should make sure that the history length is not too long (default is 1024 elements).

I am not able to reproduce this behavior. It would be helpful if you could post the VI in a version which does not need any hardware.....

Norbert 

[Norbert_B]

---

@parthabe wrote:

[...]A local variable DOES make a copy everytime it is used in the code.[...]

---

Not entirely true.... please refer to the LV help "LabVIEW Style Checklist" in the section "Block Diagram":

Avoid using local variables when you can use a wire to transfer data. Every local variable that reads the data makes a copy of the data. Use global and local variables as sparingly as possible.
Details

You can use global and local variables to write VIs efficiently, but use global and local variables as sparingly as possible. If you misuse or abuse global and local variables, particularly with array data types, the memory usage of the VI increases and the performance is affected.

You can encounter race conditions when reading from and writing to local or global variables in the same application. Race conditions are difficult to debug because there is no data dependency between different instances of the same local or global variable on the block diagram.

Consider using functional global variables instead of global variables. Functional global variables do not create extra copies of data and allow certain actions, such as initialize, read, write, and empty. They also eliminate race conditions.
 

Copying takes only place for reading of variables (locals and globals such alike). Writing to them is quite comparable to writing to the terminal (if not done from two places at the same time during execution....).

Norbert 

[Ben]

Please see this Nugget on Action Engines for info on how to share data between threads.

Re: norberts comments

1) it is a waste of time trying to update a GUI at more than 30 Hz. If if it ran at 100Hz only 1/3 of the updates would be visable. PUt your RT control logic in another loops so it is not delayed by GUI updates if neccesary.

2) The "Defer FP updates" (as of about LV 7 or there-abouts) forces a screen update when set to defer and then another after.

3) Since LV is multi-threaded every READ instance of a local requires a copy because every reader of a local could modify the data and if they where just a pointer, they would all be "stomping around in the same sand-box".

This tag on LabVIEW_Performance or this cloud or related tags contain links to threads where we have talked about making LV go fast. Somewhere in that collection you find my list of data sharing techniques listed in order of performance.

With that all being said...

I believe there was a bug in LV 8.2 ( version?) where defer FP updates was not working correctly and actually made screen updates worse and/or screwed up chart updates etc.

Just trying to help,

Ben

Message Edited by Ben on 07-15-2009 07:29 AM

[Norbert_B]

---

Ben wrote:
[...]

I believe there was a bug in LV 8.2 ( version?) where defer FP updates was not working correctly and actually made screen updates worse and/or screwed up chart updates etc.

[...]

---

Hm, true, but only in subpanels: KB

Norbert 

[Ben]

---

Norbert B wrote:

---

Ben wrote:
[...]

I believe there was a bug in LV 8.2 ( version?) where defer FP updates was not working correctly and actually made screen updates worse and/or screwed up chart updates etc.

[...]

---

Hm, true, but only in subpanels: KB

Norbert 

---

... which sadly, was my case.

Ben

[MREDAY]

Thanks all for the replies.  Coming from the Matlab/C++ world like a previous user said my prior experience is sequential based coding not data flow programming.

I have reworked my code a little bit to separate the essential pieces of the code.  I have 3 while loops now.  One for monitoring user input/controls.  one for updating indicators and charts.  and one for data processing and I/O.  i have the data processing loop to run at 100 Hz and the indicator loop to run at 50 Hz..  I just have to finish reworking the data flow.

[CoastalMaineBird]

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

I've seen this claim before but I've never seen anybody back it up.  

They're not a perfect solution for everything, but neither is anything else.

They're a perfectly valid solution for some situations.  

Can you back up your claim? 

Message Edited by CoastalMaineBird on 07-15-2009 07:59 AM

[parthabe]

---

Ben wrote:

3) Since LV is multi-threaded every READ instance of a local requires a copy because every reader of a local could modify the data

---

So, you totally support me, Ben... ?!

But your term 'requires' confuses me a bit from 'makes'.

Norbert actually said (to correct me) that it makes a copy only when it is read from a local, not when it is written to.

I think he is right.

---

Ben wrote:

I believe there was a bug in LV 8.2 ( version?) where defer FP updates was not working correctly and actually made screen updates worse and/or screwed up chart updates etc.

---

I think you are perfectly correct in this prediction. I didnt try to find that post now.

[Norbert_B]

---

CoastalMaineBird wrote:

[...]Can you back up your claim? [...]

---

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

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....

Short abstract:

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

- 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....

And a last point made up by experience:

- Both types of sequence structures often prevent the programmer to think about a good framework. The code often gets messy and therefore unreadable and not maintanable. So from the point of view "software design": Sequence structures are as bad as variables.

Norbert

Message Edited by Norbert B on 07-15-2009 08:10 AM

[Ben]

---

CoastalMaineBird wrote:

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

I've seen this claim before but I've never seen anybody back it up.  

They're not a perfect solution for everything, but neither is anything else.

They're a perfectly valid solution for some situations.  

Can you back up your claim? 

Message Edited by CoastalMaineBird on 07-15-2009 07:59 AM

---

I agree... IF....

I can declare without any question that a certain sequence can never change and nobody will ever have to look at it or understand it. These conditions are rare in my book so I avoid stacked sequences with only one exception. Stacked sequences are an excelent way to include an image of your codes design in the BD of your VI. THe code goes in frame "0" and the diagram goes in frame "1". That way, readers of my code just have to click the seq frame to refer back to the design.

I believe the intent of the above statement "Stacked sequence structures are not really good. Don't use them" does not speak to performance (aside from possibly  preventing LV from multi-threading due to artificial sequencing) but rather addresses readability adaptablity and scalability.

Just sharing my thoughts,

Ben