Here's an excellent post / explanation from Norbert.
It is found here: http://forums.ni.com/t5/LabVIEW/Having-Trouble-Copy-and-Pasteing-Local-Variable-in-LabVIEW-2010/m-p/...
@Norbert B wrote:
I think it is a good time to tell him the reason for locals being "bad":
Local variables are (using terms of other programming languages) "call by reference" only for writing. Reading is done "by value" so each reading local variable represents a copy of the value from the control the local is linked to.
Taking into account that the local variable node does not provide an error in/out for "synchronization" purpose, the read is done any time the dataflow would allow it. This "random moment in time" for reading is commonly the reason for race conditions: you read old or new data but you never know for sure.
This is the reason for using variables (globals work the same!) should be avoided. But as different persons already posted: variables have their use and therefore cannot be removed from LV. But please do not consider variables to be botch! They simply work different compared to other programming languages.
Regarding performance:
Using the terminal/wire to transfer data is using X. Variables introduce a slight overhead. Sadly, this overhead depends on the system you are running on and on the LV version.
Just to give you some figures: I use LV 2010 and the local variable is about 10% slower than writing to the terminal for update of the indicator.
The value-property node is about 1000 times slower than the terminal due to the switching of threads (as being posted before). You can "cheat" a bit by hiding/minimizing the frontpanel, but it'd be still about 900 times slower.
This is the reason why the VI Analyzer suggests you to exchange all value-property nodes with local variables. This can be done when:
a) error in/out is not used for synchronization
b) performance matters
So please make it a rule of thumb:
- Try to avoid any type of "remote access to controls/indicators". Those mechanisms are local/global variables and value-property nodes. The latter ones lack of performance due to heavy thread swaps and all of them easily create race conditions if not used properly.
- There are situations where variables come handy and can be used. Those are most of Write Once, Read Many. But you should read the info tbob linked in his "signature" because this is an elegant way to prevent using variables.
hope this helps,
Norbert
PS: Without seeing the issue you described in your very original post, we cannot give you any valuable information about the issue. So please post code where we can reproduce this. Otherwise, you will never get any answer!
