local variable vs property node->value

[Neil.Pate]

Hi All,

I have been using LV7.0 for just under two years, and am basically self taught (but with fairly strong programming experience in other languages). I think I have gotten my head around most of the concepts, just one thing still bothering me (well, one thing at the moment )

I know its best to always try and wire things together, but sometimes when you want to update an indicator from a few (only a few...) points in the program its just not really feasible  to have wires running through every case of the main state-machine. I do have a cluster of "global-ish" variables (not globals, just available to the whole main program), I just dont want to arbitrarily add controls to this cluster as although the overhead is probably small it seems wasteful?

As far as I know, there are  two ways around this, using the value property of the control/indicator, and using a local variable. Both break the data-flow paradigm, but in simple cases where there are no possible race conditions due to mostly sequential flow its probably safe to use either.

In the past I have noticed sometimes that using the value property would case the control/indicator to not get updated, but I have not been able to reproduce this problem. I have always steered clear of local variables on the advice of most people in this forum, but now I would like to know, which is the lesser of the two evils?

So my question is basically: in a bare-knuckle fight, would you rather have value property nodes on your side, or local variables??

Looking forard to hearing the answers.

cheers
Neil

ps: as an aside, I know this is not the right place for this, but I have a little rant. I seriously dislike not being able to open versions of VIs that are higher than mine (lowly 7.0). Often I browse the forum just looking to learn from other peoples good code, but I cant open the VIs, and it seems like imposing to constanly ask people to re-save their work in 7.0 format. I realise there are additional features in newer versions of LV which my version would not interpet properly, but often most of the code posted is fairly basic (but contains fundamental programming techniques that everyone can learn from).. sigh... At least with textual code (like C) you can always view the source, posssibly not compile it, but still give your brain a workout. rant over. back to using Labview (which I like far more than C!)

[EdDickens]

The simple answer to your basic question is; the local variable is actually more efficient than the Value property.

Of course there is a qualifier for that. The local variable is better because using any property of a property node causes that LabVIEW execution engine to instantly switch to the user interface thread so the front panel item can be immediately updated with whatever property is being written to it. This can cause you application to run much slower if you are constantly writing to the node. You can prove this by running the attached VI (saved in LabVIEW 6.1 for everybody’s convenience ) So if all you're writing is the Value, you're better off with the Local. But if you are also updating other properties at the same time as the Value, you might as well use the property node because you're going take the hit anyway.

Since you mention that you are using a state machine, there's a way to avoid using locals or properties to update the value from different locations. Make a state named "Update Display". Place the indicators that need to updated from different locations in this case and have them read the value from your "cluster of "global-ish" variables". Update the cluster element from where ever you need to and send the state machine to the Update Display state and everything gets updated with just a wire. The overhead involved in bundling and un-bundling a cluster is minimal. I use this in almost every state machine I build and it really works well.

Ed

[Neil.Pate]

Ed,

Thanks for your answer, I think your idea of an update step is a great one. I will keep this in mind for future wirework.

I tried to open your VI, but LabVIEW 3.0 wouldnt accept it.

Jokes aside, I didnt realise the local variable was that much quicker than using the property node, also I didnt know that all property nodes work in the user thread. Happily, I have been trying to move away from property node->value updates for a while now, and they are invoked infrequently, so they dont slow my code down at all.

Thanks again!

[EdDickens]

Here's a screen shot of the test VI so you can build it yourself. The difference in speed is really unexpected. Just out of curiosity, could you post the time differences of how it runs in LabVIEW 3. It would be interesting to see the difference.



Still try and limit you use of local variables as much as you can. Although they are faster, they do cause copies of the data to made in memory. Not that big of a deal for a single item, but if you are sending large arrays of data through variables, you could start to run into performance issues and memory problems.

Ed

Message Edited by Ed Dickens on 11-24-2005 10:43 AM

[Neil.Pate]

Ed, thanks for all your help and enthusiasm,

I was actually joking about the 3.0, 

On my insanely slow P-III 600 MHz, I get run times of

3677 ms for prop. node
15 ms for loc. var.
29 ms for direct

so thats quite two orders of magnitude faster for the local variable! proof indeed!

cheers
Neil

[EdDickens]

Isn't it interesting that the local seems faster than wiring direct!? I read an explaintion of this somewhere but can't remember it right now.

To really get good execution times, you should run those loop in separate VIs one at a time so they're not competing for CPU time, but you shouldn't see a huge difference.

Ed

[Donald]

---

@Ed Dickens wrote:
Isn't it interesting that the local seems faster than wiring direct!? ...

---

Ed,

Isn't the appearance of the local being faster (at least in this example) just due to dataflow and having a couple of different 'Tick Counts' in use?

[EdDickens]

---

Ed,

Isn't the appearance of the local being faster (at least in this example) just due to dataflow and having a couple of different 'Tick Counts' in use?

---

Partially, that's why I made the comment about moving each loop to a separate VI and running them individually so they don't fight for CPU time.

But I do seem to remember a thread either here or maybe on Info-LabVIEW where either Greg McKaskle or Stephen Mercer explained how the local could actually be faster (not better) than a wire.

I just can't find it.

Ed

[altenbach]

I modified your testing VI a bit to make it more realistic (LabVIEW 7.0). Just writing a local varaible is cheap.

Let's look at the case where we need to increment a variable in a loop. The attached demo shows 4 different ways:

1. Shift register, updating the indicator at each iteration.
2. Read local..increment...write local.
3. Read value property..increment..write value property.
4. Same as 1, but write the indicator only after the loop has finished.

Only version 4 is reasonable in such a fast, nearly empty loop and is over an order of magnitude faster than even 2 or 3. Locals and properties always update the control, something that is not desired in a fast loop. Only if the loop is slow, we might want to update during the loop, and in this case the speed penalty is insignificant.

However if we are dealing with large data structures, the extra data copies of local variables will pose a heavy performance penalty, you might even run out of memory!

Notice that the situation dramatically changes if you set the indicators to "synchronous display". Now cases 1,2,and 3 are all similar, very slow, and roughly at the property node speed (Actually, 3 is slightly faster than 1 or 2 here!!!). Only 4 is still fast as before.

[altenbach]

Of course it also depends if you are reading or writing. I added two more cases.

• (5) Read from Local variable...increment...write to value property
• (6) Read from value property...increment...write to local variable

Case (6) seems to be 20% slower than (5). Mix&Match and test... 😄