cluster packing - memory usage

[Les__Bartel]

After reading this article http://www.catb.org/esr/structure-packing/ about packing data elements in C, I began wondering if LabVIEW behaves similarly. In short, the order of elements in a cluster can greatly influence the size of the cluster. For example, if you have 4 elements in your cluster (in order) long, char, long, char, the memory requirements are 4+1+3+4+1+3=16 bytes. The two '3' byte elements are padding required for word alignment. If you change the order to long, long, char, char the memory requirements become 4+4+1+1+2=12 bytes. The last 2 bytes are padding.

The article also mentions bit fields. It does not appear that LabVIEW supports bit fields. Therefore, if you have a number of booleans, you might be better off (memory wise) to store them in a larger suitable data type and pack/unpack them yourself. The trade-off is that your code will run just a bit slower.

I assume that the tab order of the elements in a cluster is the order they are declared in memory. Thus changing the tab order can allow the user to reduce the memory footprint of that cluster. This is mostly important if you have thousands or hundreds of thousands of instances of the cluster.

Any thoughts on this?

[crossrulz]

As far as I know, LabVIEW does not do any of this padding for word alignment.  Everything is byte aligned.  You can get an idea of this by playing around with the Type Cast, Flatten To String, and Unflatten From String.

As far as Booleans are concerned, each boolean uses a byte.  Again, everything is Byte aligned.  So if you do want to save memory, you can pack the bits into an integer and manipulate the bits as needed.  This can actually be more effecient, depending on what kind of manipulation you are trying to do.

[Les__Bartel]

Wow! It looks like I might gain execution efficiency by packing my elements to force word alignment (long, long, char, char).

Now that I think about it some more, perhaps the flatten to string function does not expose the internal word alignment done by the LabVIEW compiler.

[JÞB]

The help file goes into greater detail.  DO go there for further reading. 

Briefly:

Numerics booleans and arrays are contegeuos blocks of memory and are byte alligned.

Booleans are u8s

Char arrays (Strings) are treated as any other array but require that LabVIEW maintains a lookup table of all string lengths (by pointer)

Arrays of strings may not be contegeous in memory (but their pointers are to the best of my knowledge)

Clusters may, or may not be contegeuos depending on the member datatypes (Thats the difference between the brown and pink clusters)   Contegeuos clusters can be wired to the Cluster to Array primative.

Now to address "I might gain execution efficiency by packing my elements"

Probably not.  the LabVIEW compiler does its best to do whatever optimizations it can for your operating platform.  Its pretty good- and gets better all the time.  That's one of the advantages of LabVIEW.  It does that for you.  It is also one downside- It doesn't tell you what it did- and what it does may change (Almost allways for the better)  But the performance and metrics tool can be used to help benchmark what is going on inside.

The help and online courses also touch on how to optomize LabVIEW code.  Optomization techniques in a higher level language such as LabVIEW are not the same as they are in lower level languages such as C.

[Les__Bartel]

After thinking about this some more, I have decided that it would confuse programmers if the 'flatten to string' or typecast operators did NOT pack the data elements. Therefore (with full respect to you), your example does not prove anything about the internal representation. Note: I also tried 'write to binary file', and it produced the same packed results as did your examples.

[JÞB]

---

@Les__Bartel wrote:

. Note: I also tried 'write to binary file', and it produced the same packed results as did your examples.

---

Not surprising.  a *.vi is a binary file

[nathand · Accepted solution]

The information you want is in the help under "How LabVIEW Stores Data in Memory" see the Clusters section. The short answer is, it depends on what platform you're using.