local variable vs property node->value

[Vaibhav]

---

@EdDickens wrote:

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

---

Hi Ed,

Although this thread is quite old, I have recently stumbled upon this performance question. I am curious about your mention of "Update Display" state.

I use producer-consumer style two loops programming for most of my major programs. Using queues to go to cases for each event and some cases being called by multiple events, such as updating values etc.

But I am curious about your state of update display. I change values as per conditions. So I need to have several cases for such updates, each case for different type of value change (for example, an array may have a value X in certain case and a value Y in certain other case, or in another case, some of the front panel objects are cleared or disabled and on another instance other objects are disabled and grayed out). So for this purpose if I make just one "Update Display" case, I will have to use a case structure (several case structures) inside one case on the consumer loop.

Or do you mean something different?

When the time permits, can you please post a simple example of what exactly do you mean in that description -

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".

Of course, whenever possible, I use wires instead of local variables or value property nodes.

Thanks!

[jaguirre]

Congrats to both of you.
Despite the fact that more than 12 years have passed, the issue remains valid and the dialogue between them was very fruitful for me.
It occurred to me to try the VI with an HP Omen with I7 8 cores and 2.8GHz and I thought that the difference with the PIII of Neil would be abysmal.
The resulting figures are: (I will try to paste the screenshot).

 

[rolfk]

Why should an Intel i7 Core change anything about the very fundamentals of data handling? What it does is reduce the numbers more or less by a certain factor but the relative difference has to remain more or less the same.

Writing data into a memory location, or having to go through several layers of synchronization (such as data protection inside LabVIEW itself, scheduling everything to be run in the single threaded user interface system, waiting for the operating system to eventually alot time for that thread, and then eventually getting to run the routine that can update the data value of the UI object on the front panel among all the other things that has to happen in the UI like drawing a multi mega XY graph, and then signaling the property node that everything has been done successfully and it can continue to execute).

And yes there might have been another way to handle Value properties that would not have required to go through so many layers of synchronization and the single threaded UI bottleneck but at the expenses of a very complex internal mutex handling that has a pretty high change of running at times into a mutual exclusion lockup, from which the only escape is a CTRL-ALT-DEL and then Terminate Process in the resulting "pop-up" window. 

Mutithreading is nice but sharing data between different threads is not as trivial as many casual programmers imagine. Unless you guarantee somehow that at any point in time only one thread has full access to a specific data location, you end up with corrupted data sooner than later.

[Yamaeda]

It's better to use a This VI reference to force the front panel to remain in memory.

/Y