Wire branching = new memory allocation?

[asfarley]

I've been told that branching a wire in LabView allocates memory for a new variable. This sounds unlikely - my understanding is that a wire is an output from a VI. I would have expected that a single wire would correspond to a single location in memory regardless of how many times it is branched. Can anyone clarify? 

[crossrulz]

Will it create a copy?  It completely depends on the situation.  And unless you know every little nitnoid of the LabVIEW compiler, you can't really say for certain if a data copy will happen.  But as a general rule of thumb, a wire branch is a copy of the data.

 

With your little example, I would not expect a copy in the wire.  But each terminal is a data copy.

 

Now what if you apply different gains and offsets to that input data before going to each output terminal?  That would likely have a data copy so that the operations can happen in parallel.

[asfarley]

Yeah, it makes sense that if I put the output wires through more blocks, then it would create copies. I'm wondering specifically about the situation where the wire is branched without going through separate blocks. Is the memory allocation behavior predictable in this situation?

[ned]

A wire branch NEVER creates a copy. Copies occur only at nodes. This is apparent when you use the "Show Buffer Allocation" tool. Each function determines whether it needs to modify the value on a wire. If it does, and if it can't get exclusive access to that value, then it makes itself a local copy. If, however, the value on the incoming wire isn't needed anywhere else, then the function can do its work in-place instead of making a copy.

 

I'm going to use the term "reader" and "writer" here to refer to functions that read a value off a wire, and that modify a value on a wire, although I'm sure those aren't the official NI terms.

 

If you branch a wire to multiple readers, no copy should occur. If you branch to several readers and one writer, the compiler will usually arrange to do the reads first, then the writer, so no copy needs to occur. If you branch such that you need to modify the value and also keep a copy of the original value, or branch to multiple writers, then of course copies are made.

 

In your example, I wouldn't expect the VI to make an additional copy even though there are two outputs - unless the front panel is loaded, in which case it may make copies for display.

[JKSH]

Another way to think of it is in terms of deep copy vs. shallow copy. You can think of a branch as a shallow copy -- there are two wire branches representing the same data so it looks like 2 copies, but internally they refer to the same block of memory. However, if 2nd branch needs to modify the data while the 1st branch still needs to access the original data, then the 2nd branch will fully duplicate the data (i.e. make a deep copy) and modify this copy.

 

For a more technical and in-depth look at the topic, see the VI Memory Usage article.

 

(P.S. I'f I'm not mistaken, this copy-on-write mechanism only applies to structures like strings, arrays, and clusters. Scalars (Booleans and single numbers) are always copied fully, as the impact is negligible.)

[Rolf Kalbermatter]

I'm going to use the term "reader" and "writer" here to refer to functions that read a value off a wire, and that modify a value on a wire, although I'm sure those aren't the official NI terms.

 

LabVIEW developers call your writers "stompers". They stomp on the memory they receive as input. The LabVIEW compiler is smart enough to not create a copy if only one data sink is a stomper. It schedules the code in such a way that all the non-stompers read the value first and then lets the stomper use the data.

 

It goes even so far that an input can change its stomper status based if an output of that node is wired and may reuse that input value or is left unwired.

[hooovahh]

Here's a fun little video done by LabVIEW R&D Stephen (now Loftus) Mercer, AKA AQ, from NI Week a few years ago.  At points he talks about what the compiler will do and he admits there are times that he couldn't predict what it would do, and needed more research to find out.

 

https://www.youtube.com/watch?v=YnjeZxhAolY

[pawhan11]

Nice video, explains some things