defer panel update results in slower performance

[RavensFan]

The problem with your example is that there is a race condition between the boolean value node and the defer updates.  It is very possible that the value property node executes before the panel updates is turned off, which means turning off the updates would be pointless.

[Yamaeda]

---

@maxwellb wrote:

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?

---

I would assume a Defer updates causes ALL items and panels to redraw, not just the changed ones. If, as others say, it also redraws when you defer it, i'm not that surprised.

/Y

[CoastalMaineBird]

I would assume a Defer updates causes ALL items and panels to redraw, not just the changed ones.

--- Why would you assume that, since it is unnecessary, and against the policy stated in the HELP text?

When you set this property to TRUE, LabVIEW redraws any front panel objects with pending changes then defers all new requests for front panel updates.

--- My point was that IF there are pending changes due to other things, then turning deferment ON causes a draw, and then turning it OFF causes another draw.

It's POSSIBLE that would cause an increase in CPU usage.

[Yamaeda]

Nice catch, it shouldn't redraw all. I just had a memory of forcing redraw by setting dirty bit, dont know from where though. 🙂

According to the help setting it OFF shouldn't cause redraw if nothing is pending. Maybe a bug? Or is LV being slower at redrawing full screens compared to single controls?

/Y

[maxwellb]

OriolesFan, that Boolean value node is just the way the Stop button came across in the snippet. That is ancillary.

The code I posted is running in parallel with a stacked sequence structure updating many front panel indicators. I thought that adding this little loop in parallel would limit all front panel redraws to 5 Hz and improve my CPU usage. However, it seems to have done the opposite.

[maxwellb]

Steve,

I'm using the snippet I posted earlier because I thought this way minimizes the amount of time between setting defer updates to FALSE then TRUE. Some panel changes may still happen between FALSE and TRUE, but there shouldn't be many. Almost all of them should happen between TRUE and FALSE.