Cluster performance: "single unbundle" vs "multiple unbundle"

[Intaris]

It's a surprisingly complicated question.

Are any of these VIs inlined?

When the LV compiler tries to ascertain whether a value can be read in-place or whether it needs to make a copy, there are a LOT of things which can influence that decision.

One which has gotten me in the pas:, compiled code complexity. If you have a lot of inlined VIs, the VI metric "Code complexity" is lying to you. The complexity of the code during compilation vs the complexity when looking at it in the IDE will differ significantly. And when the complexity (during compilation) gets too high, LV starts ignoring certain types of optimisation. So there's that factor to contend with. It's annoying because code which runs fine for years can suddenly become a performance bottleneck due to seemingly unrelated changes around the sub-VI. I had a case in the past where I was using IPEs, and was told my NI that this is actually not neccessary, and that using an IPE where the compiler can already know that it's in-place is actually costing me time. And since performance was paramount, I deleted the IPEs. Performance tanked (I'm talking 100x slower). I had run into precisely the situation I mentioned above. I had to re-introduce all of the IPEs. Usage of an IPE is not dependent on the compiled code complexity.

[AeroSoul]

---

@billko wrote:

---

Edit: Well of course it was the last thing I tried, because it worked, but you know what I mean.  😄

---

Similarly, your car keys are always in the last place you'd look. 🙂

[JÞB]

A little esoteric knowledge since both Mark and Bill are correct half the time.

Do multiple Unbundles force LabVIEW to copy the cluster data at each wire branch or can the compiler optimize and reuse the cluster data copy?

The answer may be.  If the cluster wire is brownish the data is contiguous in memory and the compiler might feel safe enough to operate on the same buffer otherwise, the cluster wire is not brownish (pinkish or greenish) and the data may be non-contiguous in memory and only copying the whole cluster data is safe.

To be honest, I disagree that branching the cluster to multiple unbundle nodes is cleaner than bending a few element output wires if you properly label your wires!

And if you still don't like that, make the cluster a class and use property nodes.  Or treat it as such in an action engine with get and set <element> actions wrapped with the "Nirvana" AE API vis.  Either of those choices force LabVIEW to share the Cluster data buffer in either the Class or on the SR/FBN of the AE Core.

[billko]

---

@JÞB wrote:

A little esoteric knowledge since both Mark and Bill are correct half the time.

Do multiple Unbundles force LabVIEW to copy the cluster data at each wire branch or can the compiler optimize and reuse the cluster data copy?

The answer may be.  If the cluster wire is brownish the data is contiguous in memory and the compiler might feel safe enough to operate on the same buffer otherwise, the cluster wire is not brownish (pinkish or greenish) and the data may be non-contiguous in memory and only copying the whole cluster data is safe.

To be honest, I disagree that branching the cluster to multiple unbundle nodes is cleaner than bending a few element output wires if you properly label your wires!

And if you still don't like that, make the cluster a class and use property nodes.  Or treat it as such in an action engine with get and set <element> actions wrapped with the "Nirvana" AE API vis.  Either of those choices force LabVIEW to share the Cluster data buffer in either the Class or on the SR/FBN of the AE Core.

---

That's very interesting!  At any rate, I've moved away from this because, if you have to split up your unbundles like that, your VI is probably too complicated and needs to be broken up into subVIs.

[JÞB]

---

@billko wrote:

---

@JÞB wrote:

A little esoteric knowledge since both Mark and Bill are correct half the time.

Do multiple Unbundles force LabVIEW to copy the cluster data at each wire branch or can the compiler optimize and reuse the cluster data copy?

The answer may be.  If the cluster wire is brownish the data is contiguous in memory and the compiler might feel safe enough to operate on the same buffer otherwise, the cluster wire is not brownish (pinkish or greenish) and the data may be non-contiguous in memory and only copying the whole cluster data is safe.

To be honest, I disagree that branching the cluster to multiple unbundle nodes is cleaner than bending a few element output wires if you properly label your wires!

And if you still don't like that, make the cluster a class and use property nodes.  Or treat it as such in an action engine with get and set <element> actions wrapped with the "Nirvana" AE API vis.  Either of those choices force LabVIEW to share the Cluster data buffer in either the Class or on the SR/FBN of the AE Core.

---

That's very interesting!  At any rate, I've moved away from this because, if you have to split up your unbundles like that, your VI is probably too complicated and needs to be broken up into subVIs.

---

Since I did mention Nirvana...... you should get some Idea from this incomplete lvlib