Why can't I send a picture to the back of my diagram?

[X.]

Which I kudo-ed in the past...Agreed.
So I guess what I described could be viewed as a temporary (!) workaround...

[altenbach]

This thread started our very generic, but now we are specifically talking about passthrough wires.

How about an option to hide passthrough wires whenever they are not accessed in a certain frame?

Still, we are talking about code here and there are only objects of interest to the programmer. Somehow I don't think hiding code stuff is very productive in general, because it makes it much harder to debug. What should happen in highlight execution? How would you probe stuff?

[drjdpowell]

---

@X. wrote:

---

@tst wrote:

If you have multiple tunnels, I would suggest considering bundling them into a single cluster or class. Done - your wires are no longer visible.

---

That is not always a practical option (as in the masked diagram above). For instance, the wire carry massive amount of data, therefore the overhead in bundling/unbundling is a heavy price to pay.

When you have a multi-case structure in the loop (as in the diagram above), you then have to unbundle/bundle in each case you are using even a single wire. That requires naming conventions that distinguish between same type wires (and thus that requires Named bundles. Each time you modify the type of ONE wire, you have to modify the bundle type, etc...

---

I suggest you give a cluster (with named elements) a try.  Bundling and unbundling is usually done in place, and thus costs nothing regardless of data size.  And unbundling things by name is a very clear coding style that reduces the need for explicit documentation.

[altenbach]

---

@drjdpowell wrote:

I suggest you give a cluster (with named elements) a try.  Bundling and unbundling is usually done in place, and thus costs nothing regardless of data size.

---

I agree in general, but sometimes e.g. array sizes do change and if you have a cluster of several multidimensional arrays, changing the inner array sizes is probably not very gently on the memory manager. Just guessing, I have not really made extensive tests...

[drjdpowell]

I beleive (may be wrong) that when a cluster holds an array, the cluster actually holds a pointer to the array, and thus changing the size of the array doesn't affect the cluster itself (other than updating the pointer to the new memory location of the array.  I think, I should check...

[X.]

If that would be the case, I may try changing my programming style. Maybe some NI input would be timely? Some of these wires hold several 100 MB (or GB depending on the computer I am using) and I'd rather not have buffer allocations or memory copies when I change a simple boolean element of the cluster, for instance...

[drjdpowell]

---

@drjdpowell wrote:

I beleive (may be wrong) that when a cluster holds an array, the cluster actually holds a pointer to the array, and thus changing the size of the array doesn't affect the cluster itself (other than updating the pointer to the new memory location of the array.  I think, I should check...

---

Found a reference: How LabVIEW Stores Data in Memory.   Clusters store "handles" to Arrays (and also Strings and Paths).  So changing the size of an array shouldn't require copying the rest of the cluster.

[X.]

OK, worth trying for next diagram... Wire naming will become critical, if one doesn't want the unbundle + bundle objects to occupy the full diagram width...

As mentioned before, the problem with bundled wires is that they indeed need to be named to be of practical use, which requires a cluster definition somewhere (preferable typedef-ed).

It cannot always be outside the loop because you can't always initialize a shift register (and BTW, that bring in another subtlety, which is that some SR need to be, and some other should not be, initialized).

If not outside, then it needs to be defined inside. Should we have a special "wire bundle definition" case? Could be done for a Case Structure (I remember seeing an example like that in the micronugget thread a while back), but this would need an artifice for other types of structure (e.g. Event Structure).

Finally, although I haven't had to use one lately, this prevents from using stacked SR (or whatever the use of previously stored value in a register are called). In particular if one of the wire bundle element is a gigantic array...

Some related threads:

Are-bundle-and-unbundle-expensive-operations

cluster-array-performance-penalty (dates back to 2007 so these performance metrics might be outdated)

[drjdpowell]

See the JKI state machine as another example of using a cluster.  Their cluster is defined in their "Data: initialize" case.  Note that they don't cluster everything, but instead use separate shift registers for their "state queue" and the error wire.  In the same way, one could choose to treat some data individually.  But putting most data items in a single cluster will greatly improve code readability.

[X.]

If somebody would be so kind as to revisit the benchmark thread I posted above. It discovered a performance hit in one of the way of using the unbundle/bundle (unnamed though, so this could be a diffferent story for named clusters). The NI guy who chipped in said that they had decided against fixing it at the time (LV 8.2), so it may still be lingering around.

In the meantime, one can still limit the bundling to "light" wires only, keeping the "heavy" ones on their own shift register...