Does rapid Unbundle by Name affect performance?

[Thomas444]

I did some basic tests on cRIO 9057 and they were not reliably confirmative for any conclusion. I am not talking about classes, but about pure data clusters.

Tests was run like this. I had cluster with number and string inside, it went into For Loop with 200000 iterations, unbundled inside into string and int32 and compared with previous value (shift registers) to include some maths. Comparison results (bools) are indexed into array. In the second comparative loop, the cluster contents are unbundled before loop and wired separately. VI is executed in Run Continuously mode. Results were about 77 ms for unbundling inside and 74 ms for unbundling before.

Is that it, the difference, and how to test that correctly in LV?

[GerdW]

Hi Thomas,

when it comes to benchmarking you should wait for Christian (Altenbach) to jump in.

Until then you should provide your VI you used for your test…

Do you run your test with a single scalar cluster containing just 2 elements? What's the point in unbundling this cluster 200k times?

[LucianM]

Difference should be negligible but it's always recommended to move code which generates the same results at each iteration outside of the loop. Can you post the benchmarking code that you ran? We can check if you measured correctly. Also, try to run the loop for more iterations ( like 1,000,000 times) if the difference is that small.

[drjdpowell]

What are you expecting to see?  Unbundling by name isn't an actual run-time operation.  By itself, it takes no time at all, so does not matter "where it happens".

[Yamaeda]

Post the VI so we can see where you go wrong. 🙂

Technically having an unbundle outside of the loop instead of inside should save a memory access, assuming the compiler can't optimize it away, but i'm surprised if it actually accounts for 3ms difference over 200k iterations. 

To ask what'll probably be Altenbachs first question; Do you have Debugging disabled on the VI?

[LucianM]

---

@drjdpowell wrote:

Unbundling by name isn't an actual run-time operation.  By itself, it takes no time at all, so does not matter "where it happens".

---

Makes sense but are you sure it is valid for LabVIEW? In the Advanced Architectures for LabVIEW printed course 2011 they discuss the way you can save state data inside QMHs: all data in one cluster in one shift register and you bundle and unbundle when needed or several shift registers for each piece of data. They say that bunling/unbundling performance hit was minimized several years ago so this should not be a reason for choosing multiple shift registers.

Also, in LabVIEW 2018 bug fixing list, there is a solved issue: "Bundling class data is slower than bundling cluster data". Doesn't this mean that it is not an NOP?

[Yamaeda]

Unbundling is the same as a struct property read in a C-based language, so it's the same as 'int x = struct.property;'. It's not a NOP, but the compiler knows it's the struct+offset address it accesses, so there's no lookup or any big operation. (The mentioned bug is clearly different, as a class is basically a glorified cluster and changing the data should be as fast)

OP mentions comparing to previous value, so it i'd take a guess the compiler might recognize that it's being fed a static value and does a constant folding on the comparison, saving a number of clock cycles.

[Thomas444]

Here it is. The problem with labview is that I can't guess how simple the process inside the loop can be, so that labview doesn't optimise it out completely. So i added some math inside but maybe it is unnecessary.

[LucianM]

---

@Yamaeda wrote:

The mentioned bug is clearly different, as a class is basically a glorified cluster and changing the data should be as fast

---

Yes but from the explanation in details: Unbundling or bundling class data is substantially slower than bundling or unbundling a cluster, I understood that bundling/unbundling clusters still does something but much faster than for classes.

[Yamaeda]

Never test in parallell!

You have debugging enabled!

(i'll check some more)