Writing Values To Front Panel Controls (Most Efficient Method)

[dacad]

Just for kicks, I put this in an empty project and also added a shared variable case.  Ran them all as is and then again with the shared variable bound to the "Value" indicator.  Here is what I got

Method                                       No Binding           Shared variable bound to "Value"

Terminal                                        9 ms                   9 ms

Local Variable                              11 ms                  8 ms

Shared Variable                           535 ms                4.2 sec

Property Node                             33.1 sec               36.5 sec

Reference                                    33.9 sec              37.0 sec

Set Control Value                         776 ms               803 ms

Set Control Value by Index          46.7 sec             57.7 sec

Odd that the Local Variable time actually decreased when with the bound condition of the indicator.  This was consistent though.

Might go back and add a global variable just to see where it falls in though I try not to use these any more.

These times look about right?  Since they are all relative to computer porcessing speed, I'm sure they will vary from system to system but the delta's between the various options should be somewhat consistent.

[David-A]

---

@dacad wrote:

Just for kicks, I put this in an empty project and also added a shared variable case.  Ran them all as is and then again with the shared variable bound to the "Value" indicator.  Here is what I got

Method                                       No Binding           Shared variable bound to "Value"

Terminal                                        9 ms                   9 ms

Local Variable                              11 ms                  8 ms

Shared Variable                           535 ms                4.2 sec

Property Node                             33.1 sec               36.5 sec

Reference                                    33.9 sec              37.0 sec

Set Control Value                         776 ms               803 ms

Set Control Value by Index          46.7 sec             57.7 sec

---

The control value by index doesn't look right. Here's what I got on my machine.

[dacad]

I ran it again outside the project and eliminating the shared variable and the Set Ctrl by Index ran around 700 ms.  Maybe the overhead of being in a project along with the presence of a shared variable has an impact?

[crossrulz]

The set control by index code also has the overhead of finding the index each time you go to write it.  To get the real performance boost, you should look up the index once before the FOR loop and then use that index to update the value.

[GregFreeman]

Sorry to interject. This is an interesting case study for sure, but I would consider leaving it at that: a case study. In my however many years of LabVIEW development I have never had a need for this, so while figuring out the most efficient solution, don't forget the balance between code that someone can read and code that is more efficient but completely obfuscated. I'd much rather lose some minor efficiency and have a process that just pumps data via some transport (queue, user event, etc) to a loop that is dedicated to handling UI updates, which I can quickly understand. Consider the YAGNI and KISS principles and don't overdesign if you aren't doing massive UI updates.

[rolfk]

What is obfuscating in using terminals whenever possible and eventually local variables if unavoidable?

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events, to avoid duplication of the same code in multiple event handling cases (and very rarely when implementing a generic VI that does quite a bit of processing with subsequent update of a control value). However this last one is most likely already a good candidate for an XControl instead.

[crossrulz]

---

rolfk wrote:

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events

---

I'd also argue if you are setting a value at the same time you are setting other properties.  Just drag down the property node to accept multiple inputs.  It should just be one thread swap the the UI if in the same property node (based on my understanding of how the property node works).

[dacad]

---

rolfk wrote:

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events

---

The only issue w/ local variables is that to maintain the linearity of the execution, you have to put them in a frame or other type of case structure whereas nodes can get wired in and as crossrulz points out, you can tap into many parameters at once.  When I have several different nodes in a given location I often stack them and wire the error wire to the input but leave the output open just to get the execution flow that I need.

On a semi-related topic concerning shared variables, I am going to start a new thread asking about timing of these in conjuntion with refrenced vi's. Noting it here so you guys that get to work with LV a lot more than I do might have some thoughts when you see the thread.

[crossrulz]

---

@dacad wrote:

When I have several different nodes in a given location I often stack them and wire the error wire to the input but leave the output open just to get the execution flow that I need.

---

With that example you are showing, I would use a sequence structure and local variables.  It just isnt' worth the performance hit to me to write a value to a property node.  Now if you were setting the Visibility and the Value properties OF THE SAME CONTROL, that's when setting the value with a property node makes sense.

[rolfk]

---

@dacad wrote:

---

rolfk wrote:

The only legit use of the Value Property Node in my opinion is when using the "Value w. Signal" version for UI updates as reaction of other UI events

---

The only issue w/ local variables is that to maintain the linearity of the execution, you have to put them in a frame or other type of case structure whereas nodes can get wired in and as crossrulz points out, you can tap into many parameters at once.  When I have several different nodes in a given location I often stack them and wire the error wire to the input but leave the output open just to get the execution flow that I need.

On a semi-related topic concerning shared variables, I am going to start a new thread asking about timing of these in conjuntion with refrenced vi's. Noting it here so you guys that get to work with LV a lot more than I do might have some thoughts when you see the thread.

---

Well I would use locals and put the false constant and the 1 constant in the loop. 

LabVIEW is since many versions smart enough to consider constants inside a loop as invariant code and not evaluating them on every loop iteration again.