What is difference between local variable and property node ?

[Jarrod_S.]

One thing people haven't mentioned yet that can be very important in terms of performance when choosing between locals and property nodes is that property nodes (implicit or by reference) cause a syncronous update of the control on the front panel whenever you update the value from them. That means LabVIEW has to stop whatever it's doing, jump to that front panel and update the control. If you do this a thousand times in a loop, you're looking at at least 1000 thread swaps and 1000 redraws. Nevermind that the human eye can't possibly see each of the 1000 updates, that is a huge burden on your system resources.

If you update a value using a local variable, LabVIEW may make a copy, but it can still be smart about when to update that control on the front panel. LabVIEW's default behavior is to store all front panel update requests in a queue and service all of them at once about 60 times a second or so. This provides (or is intended to provide) minimal thread swaps for maximum visual acuity.

[chilly_charly]

---

Jarrod S. a écrit:
One thing people haven't mentioned yet that can be very important in terms of performance when choosing between locals and property nodes is that property nodes (implicit or by reference) cause a syncronous update of the control on the front panel whenever you update the value from them. That means LabVIEW has to stop whatever it's doing, jump to that front panel and update the control. If you do this a thousand times in a loop, you're looking at at least 1000 thread swaps and 1000 redraws. Nevermind that the human eye can't possibly see each of the 1000 updates, that is a huge burden on your system resources.

If you update a value using a local variable, LabVIEW may make a copy, but it can still be smart about when to update that control on the front panel. LabVIEW's default behavior is to store all front panel update requests in a queue and service all of them at once about 60 times a second or so. This provides (or is intended to provide) minimal thread swaps for maximum visual acuity.

---

This is illustrated by these experimental results : relative execution time for the replacement of 100 000 array elements :

wires                    1
locals                   1607
L2 type globals   2257
Property nodes   15000

[Ben]

CC,

Could you please post the VI's used to generate these numbers?

Thank you,

Ben

[Jarrod_S.]

If anyone wants direct proof of how expensive redraw operations are (in LabVIEW or with anything), turn on the Windows Task Manager (Ctrl-Shift-Escape) and click on the Performance tab. Then take any open window, LabVIEW-based or not, and start dragging it around really quickly. Watch your CPU rise... 🙂

[Kevin_Price]

---

- you should always seperate naming for the GUI from the naming on the block diagram. for the GUI use the "caption", for the diagram the "label". the locals name is the controls label.

---

I'm curious -- I very rarely display the GUI caption, preferring to display either the label or nothing at all.  Since you advise always keeping the names separate, you must have a very different approach than me.  What's the thought process behind your rule-of thumb?  It's only on relatively rare occasions that I find need for the caption, usually for generic multi-use indicators whose present contents are id'ed by the run-time-writeable caption text. 

During development, I *like* having the same name on both front panel and block diagram, and having both update in sync if I change one.  I developed my rule of thumb when I was still pretty green with LV after a few frustrating debug adventures where captions and labels got criss-crossed and out of sync.  The code did some calcs and wrote to an indicator labeled "param 3".  On the GUI, that indicator showed only its caption, "param 1".  A *different* indicator had a visible caption "param 3" but was labeled something else on the block diagram.    What a mess!

-Kevin P.

[Ben]

Kevin asked

" What's the thought process behind your rule-of thumb?"

I believe that comes from the VI Checklist!

"

The name of a control or indicator should describe its function. If the control is visible to the user, use captions to display a long description and add a short label to prevent using valuable space on the block diagram.

"

See here

http://zone.ni.com/reference/en-XX/help/371361A-01/lvdevconcepts/checklist/

Ben

Message Edited by Ben on 09-21-2006 02:42 PM

[Kevin_Price]

Guess I'm spoiled -- most of my stuff is used by myself or other techno types that don't miss the extra verbage.  I definitely see now why a nice long descriptive caption can be better than a shorter label, and will try to follow the suggestion more often when I find myself with extra screen real estate.  That doesn't seem to happen very often.  The people I deal with generally seem to want to have all possible display information visible all the time.  Pop-ups aren't highly regarded -- "I don't want to miss seeing X because Y was in the way..."

Curious again now.  Another reason I like the shortish labels is for lining up various numeric controls / indicators.  If I've got 5 different numerics that only need to display up to, say, 7 characters, I can easily line them up next to each other left to right provided the labels are also about 7 characters each.  If I went with, say, 25-char descriptive captions, it'd be hard to lay them out without getting much uglier.  Well, uglier to my eye anyway...

-Kevin P.

[shoneill]

it's also recommended for localization purposes....

You can change the caption programatically, but the label is fixed.

If you want to switch languages, you have to work with captions (or strings, but this is messy).

Shane.

[Ray.R]

---

@jarrod S. wrote:
One thing people haven't mentioned yet that can be very important in terms of performance when choosing between locals and property nodes is that property nodes (implicit or by reference) cause a syncronous update of the control on the front panel whenever you update the value from them. That means LabVIEW has to stop whatever it's doing, jump to that front panel and update the control. If you do this a thousand times in a loop, you're looking at at least 1000 thread swaps and 1000 redraws. Nevermind that the human eye can't possibly see each of the 1000 updates, that is a huge burden on your system resources.

---

Wow...  This one I did not know..  😮

Interesting..  😮

Glad this forum exists!  🙂

[devchander]

It looks like we all just compiled a thesis on the subject

---

Glad this forum exists! 

---

Exactly!