08-25-2014 09:44 AM
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.
08-25-2014 10:47 AM
@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.
08-25-2014 11:02 AM
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?
08-25-2014 11:09 AM
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.
08-25-2014 12:16 PM - edited 08-25-2014 12:17 PM
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.
08-25-2014 12:47 PM
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.
08-25-2014 02:02 PM
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).
08-25-2014 03:31 PM
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.
08-25-2014 03:57 PM
@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.
08-25-2014 05:17 PM - edited 08-25-2014 05:18 PM
@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.