Unwired error inputs cause buffer allocation

[Broken_Arrow]

Only recently, while playing "Hide the Dots", have I noticed that not wiring the error input on functions (such as Notifiers, Queues, or Property Nodes) may come at a memory cost.

If an error cluster is X bytes, and you have dozens of these unwired (lets say) Notifiers laying around, is the buffer allocation [ X bytes * n Notifiers ]? Correct me if I'm wrong, but did the old Notifier have error in/out?

Edit: I know that not wiring the error may result in a race condition, non-LabVIEW-esque program flow, etc, but I'd like to talk about the memory aspect of this only.

Message Edited by Broken Arrow on 04-09-2009 10:48 AM

[mzaleski]

Is there a specific reason you aren't wiring your error clusters?  99 times out of 100, you want them wired to properly report and handle edge cases while developing and then deploying your app.

[altenbach]

Just curious, do you have automatic error handling enabled?

[Broken_Arrow]

Altenbach, yes it is enababled. 

[Broken_Arrow]

enabled.

[Will_S. · Accepted solution]

Hi all,

Since the "error in" is only a recommended terminal, when it is not wired LabVIEW must locate and assign default values for that input. In order to do so, some memory must be allocated. Therefore, not wiring your error inputs as well as any non-required terminals will in fact increase the initial memory allocation. However, this additional allocation should be minimal in comparison to the rest of your VI.

[Broken_Arrow]

Excellent. I can't imagine everyone out there wires up every single Property Node, etc. I'm glad the penalty is minimal, although it would be nice to just right click and set property nodes to not have an error. I learned on Version 5, which I think the nodes didn't have error in/out back then, so I got used to not wiring it early on.

Thanks for responding, Will!

[Jarrod_S.]

I can't give too many specifics, so consider it hearsay, but I know that many primitives (functions that aren't subVIs) don't actually do work for terminals that aren't wired. They can tell at compile time whether an input or output is wired and decide what code to script accordingly.

For instance, I've heard that if you don't wire the Elements output of the Queue function Get Queue Status, then it won't actually ever query those values from the queue. The code to do that is never even created.

Another example where you can see this in effect is Format Into String. If you don't wire the output string of the Format Into String, then it won't produce an error for an invalid Format String. Why not? Because it's never actually doing the format operation, since there's no output location to put the data.

My whole point here is that LabVIEW probably optimizes away a lot of unwired code when it comes to primitives, and this may in fact include the error terminals if you don't have Automatic Error Handling enabled. The dots tool might not take this into account. It's all pure speculation, but I thought I'd share.

[Ben]

---

Jarrod S. wrote:

I can't give too many specifics, so consider it hearsay, but I know that many primitives (functions that aren't subVIs) don't actually do work for terminals that aren't wired. They can tell at compile time whether an input or output is wired and decide what code to script accordingly.

For instance, I've heard that if you don't wire the Elements output of the Queue function Get Queue Status, then it won't actually ever query those values from the queue. The code to do that is never even created.

Another example where you can see this in effect is Format Into String. If you don't wire the output string of the Format Into String, then it won't produce an error for an invalid Format String. Why not? Because it's never actually doing the format operation, since there's no output location to put the data.

My whole point here is that LabVIEW probably optimizes away a lot of unwired code when it comes to primitives, and this may in fact include the error terminals if you don't have Automatic Error Handling enabled. The dots tool might not take this into account. It's all pure speculation, but I thought I'd share.

---

Back in the day ....

when I took the LabVIEW Advanced course they used to teach us exactly that as well as tirivia like the upper terminal of two input "Add" nodes would re-use the buffer of the top input etc.

More recently I was reminded about that leason when I was trying to use the "invoke node Get image" to "jiggle the handle" and get LV to update a graph on a hidden tab page. If I did NOT wire any of the values coming back from the "Get Image" the cludge had no effect. When I wired at least a single value coing from the invoke node the work-around had its desired effect.

Ben