defer panel update results in slower performance

[MREDAY]

Hello,

I am having a problem when using the Front Panel (FP) "Defer Panel Updates" property to control the FP refresh rate.  When I use the property it results in a significant slowdown of the VI versus letting the FP run freely in asynchronous mode.  I would like to update several Indicators and Charts at a 10ms update rate, which it is currently unable to keep up with.  So instead of forcing a FP refresh every time and indicator or chart changed within the 10ms, I wanted to force it to do it just once at the end.  My VI is constructed like so:

While Loop

  Event Structure (10 ms timeout, In the Timeout event it updates the Indicators and Charts)

    Stacked Structure with the following steps:

      0: Set Defer Panel Updates to True

      1: Update single precision, scalar indicator

      2: Update single precision, 6x1 array

      3: Update strip chart #1 (13 plots, 1024 buffer, single precision)

      4: Update strip chart #2 (6 plots, 1024 buffer, single precision)

      5: Update 6 indicators (3 pulldowns with strings, 3 single precision arrays (hidden indicators))

      6: Update 3 indicators (2 single precision 6x1 arrays and 1 single precision 3x1 array

      7: Set Defer Panel Updates to False (force refresh)

Any ideas on why my performance is worse doing this?

Adam

[Norbert_B]

Adam,

there are different things you should think about:

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

b) The human eye can acquire about 30 frames per second (30fps, or in other words: the eye acquires pictures with 30Hz). So updates more often then 30 times per second are not necessary (which is about 33ms)

c) Updates of controls in the timeout event are.......well, i'd say, very surprising. I'd expect the program to only update elements where the value has changed......

d) Further points would be wild guessing without seeing the code first..... 

hope this helps,

Norbert 

[MREDAY]

a) stacked vs. flat.  user preference as i understand it, i do not believe has any impact on runtime but i have not investigated.  most people prefer flat so that you can see all the code.  i tend to prefer stacked to minimize block diagram space. 

b) I understand the human eye cannot process the information that quickly.  but from a programatic standpoint it's possible and i was trying to avoid explicity running sections of code asynchronously just for that purpose.

c) not sure what you are trying to say here.  but from what i understand, if the value or a control/indicator changes a FP update gets added to the queue to execute in the GUI thread.  so my intent was to schedule 1 update every 10 ms instead of 12.

d) i'll try and post the code, gimmie a little bit.

Message Edited by MREDAY on 07-14-2009 09:12 AM

[MREDAY]

[MREDAY]

i wasn't sure what the best way to post the code was.  i converted the stacked sequence to flat to reduce the amount of image captures to upload.

[Norbert_B]

Adam,

ok, this code can blow up execution times quite easily:

- Sequences of any kind (not only stacked) are not recommended except on FPGA targets. Don't use them.

- Variables are not good, esp. when reading because they copy the value. Don't use them.

- You have included .NETinteraction. Does this maybe cause a large delay?

I recommend you not to use a timeout event case to update the UI. Please update only indicators in event cases where their values are actually changed. This is far better in regard of performance.

You told us that "defer panel update" introduced a slowdown in your application. What was the code looking like before you inserted this property? Did you already worked with the timeout event the way you do it now?

hope this helps,

Norbert 

[MREDAY]

The .Net code runs in real-time.  I have a test client independent of Labview I have tested that with.  In addition, if I disable all the indicators and charts updating with the exception of the .NET related stuff the code is able to maintain the 100 Hz rate I desire within Labview.  Once I start executing other portions of the code (charts and indicators) the code slows down to about 10-20 Hz rate.  Then when I reworked the code to defer front panel updates is slowed down to about 1-5 Hz.

The code looked the same without the defer front panel change.  so the first and last frame of the stack did not previously exist.

With regards to the variables, I'm not hurting for memory when I profile to code so from that standpoint it hasn't been an issue.  I would like to avoid the data copy if I could.  What is the recommended way to pass data to asynchronous parts (or different functional parts) of the block diagram?  The only methods I know if (1) direct wiring, (2) local variable and (3) property reference.  I read the efficiency of passing data was in that order.  I assumed a read local variable did not make a copy and it was really just passing a pointer to memory.

Can you elaborate on the sequences statement?  I thought sequences were just decorative ways of organizing code and did not have any performance impact. 

I appreciate the help.  I'm not a Labview expert (my specialty is MATLAB) but would like to understand and improve my Labview coding.

Adam

Message Edited by MREDAY on 07-15-2009 06:27 AM

Message Edited by MREDAY on 07-15-2009 06:30 AM

[MREDAY]

i see now in the context help for sequences that flat is better than stacked for performance.

[parthabe]

---

MREDAY wrote:

What is the recommended way to pass data to asynchronous parts (or different functional parts) of the block diagram?  The only methods I know if (1) direct wiring, (2) local variable and (3) property reference.

---

If you mean different disconnected parts of code by the term 'asynchronous', then direct wiring is NOT the correct method. Only the other two will apply.

Direct Wiring IS meant to establish dataflow in your code.

LabVIEW is a general-purpose GPL [Graphical Programming Language], mainly based on the Dataflow execution model, unlike C which follows a Sequential execution model.

So, it is better to establish dataflow in your code in a more natural way by following State Machine architecture with Error flow also (using Error In Error Out clusters among nodes & SubVIs).

---

MREDAY wrote:

I assumed a read local variable did not make a copy and it was really just passing a pointer to memory.

---

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

Actually. the reference to a variable (for the use of a generic property node), acts as a pointer to memory. But this is also not fully similar to that in its totality. You can just take this as an example for differentiating local variables & property nodes accessed thro' references.

[muks]

Since You had mentioned that u know matlab, You can use "Math script" And use matlab syntax. Anyway i feel I migrated for good from matlab to labVIEW