Global vs Local variables in performance-critical loops

[Ken_Brooks]

Okay, I'm getting quite an education here. Now I want to ask you guys to compare the virtues of three strategies that have been mentioned:

　

1. Functional global

2. Queue

3. Channel wire

　

In Channel wire terminology, I think what my problem requires is the Messenger variety.  Commands must not be lost.

[Ken_Brooks]

BTW, in my LabVIEW 2017 a search of the Functions palette with the phrase "channel wire" finds me nothing! Where do I go to create these?

[Ben]

---

@Ken_Brooks wrote:

BTW, in my LabVIEW 2017 a search of the Functions palette with the phrase "channel wire" finds me nothing! Where do I go to create these?

---

Drop a control of the type of data you want to transfer via a channel wire and then right-click and select

Create >> Channel Writer

THe pop-up will offer pictures of the various type of channels.

Ben

[tyk007]

---

@crossrulz wrote:

---

@tyk007 wrote:

Each local variable node call requires the UI thread, and there's only one of those - so your calls will only execute one at a time, as well as sharing time with the UI and other "root loop" house-keeping.

---

Completely WRONG.  A local variable does not have anything to do with the UI thread.  Writing to a local variable acts the same as writing to a terminal, just with more memory usage.  It will put the data into a buffer and when the UI thread is allowed to run again, it reads the data from said buffer to update the graphics.  I think what you were trying to refer to are the Value Property Nodes.  Property Nodes that are referenced to anything on a front panel have to run the the UI thread and force redraws.

---

You're right, thanks for clarifying. I had quickly assumed the OP was talking about property nodes but a re-read shows he was not! That's what you get for replying too quickly.

[billko]

---

@Ben wrote:

---

@drjdpowell wrote:

Note: the OP is using TCP/IP, and is thus nowhere near "tightly timed" enough for the relative overhead of the various techniques to matter.

---

Not all of EthernetIP is TCP/IP.

Datagrams can be very fast.

Ben

---

Datagram for Mr. Mongo!

[Kevin_Price]

Okay, I'm getting quite an education here. Now I want to ask you guys to compare the virtues of three strategies that have been mentioned:

　

1. Functional global

2. Queue

3. Channel wire

---

4. Notifier

Your initial posting sounded like you want your tightly timed loops to always have access to the latest data values when they do their calcs & controls.   That sounds like a decent use case for a global variable.   A so-called functional global that only reads or writes would probably be an acceptable (but unnecessary) substitute.

   I've also added possibility #4, the Notifier.  It shares the "most recent value" feature of a global but it also provides the option of signaling.  The reader of a Notifier gets to decide whether to immediately read the most recent old value or wait until the next time a value is written to the Notifier.  An app might exercise both use cases at once in different parts of the code.

   A global is likely more efficient to access, but a Notifier can support signaling if your app has a use for it.   I'd pick one of those two.  

   A Tag channel might also be useful, but I don't really know my way around Channels enough to make that a recommendation.

　

---

@Ken_Brooks In Channel wire terminology, I think what my problem requires is the Messenger variety.  Commands must not be lost.

Now this sounds like a very different kind of requirement / expectation.  Losslessness dictates *against* both globals and Notifiers.  Queues become a more natural fit, though limited to one reader.  Dynamic Events are lossless and support multiple readers, but have a bigger learning curve.  Certain kinds of Channels seem to be lossless, but I don't know particulars.  So for losslessness, I'd pick Queues due to simplicity and personal familiarity.  

-Kevin P

[wiebe@CARYA]

---

@Ken_Brooks wrote:

1. Functional global

2. Queue

3. Channel wire

4. DVR

---

Channel wires (at least the messenger) are often wrappers around queues. So they will be faster to build, but they do add a tiny bit of overhead. If you don't need all the channel wire's functionality, a queue will be marginally faster.

I'd say a FG keeping an array of values can be made very efficient (circular buffer pattern), but a queue will be more efficient (whether in a channel wire or not). But the proof of the pudding is benchmarking.

A DVR has some benefits over a FG, for example it can be put in a class, and that class can be instantiated multiple times. For a FG that is more difficult, as it's more like a singleton. Performance wise I think there would be little difference. In a FG, the VI would prevent concurrency problems, in a DVR the in place element structure would do that. Otherwise, the memory model is more or less the same. Some downsides too, the DVR will stop existing when the top level VI that instantiated it stops. That makes DVRs much harder to debug. A sub VI using the buffer won't be able to run properly when the main VI is stopped.

I really doubt you should worry about these kinds of performance differences. This might make a tiny bit of difference, but if you're in that region of tweaking, you'd better off upgrading your host. Or wait a few months and then upgrade.

You need to benchmark to know for sure if this is even slowing you down. Choose a decent implementation that is practical to implement. Benchmark, and only if it's a problem, optimize. Changes are the data transfer is not significant compared to other thinks happening (like windows downloading upgrades).

[crossrulz]

---

@Ken_Brooks wrote: Commands must not be lost.

---

In that case, use a Queue.  When you get into a messenger or stream, queues are your friend.  That is unless you are using Channels.  In that case you just need to choose the appropriate channel type for your requirements.

[altenbach]

I am surprised that nobody mentioned the shared variable (single process).

[wiebe@CARYA]

---

@altenbach wrote:

I am surprised that nobody mentioned the shared variable (single process).

---

AKA über global .