Arrays of Objects memory hit

[yenknip]

I am creating a sequencing module for a rig, and eventually the data structure will be pretty large.

The data structure is as folows:

- An experiment has a single starting step (usually a loop)

- a loop stores an array of chld steps which will be iterated through

- a step can be a state or further nested loops.

A whole experiment data structure could well be storing a few hundred steps (a loop contains an array of loops and so on), and this will take up a notable amount of memory. If child steps are stored in arrays, LabVIEW lore states they will be stored in sequential memmory, but if they are dynamically referred on to steps and loops, will they still be in sequential memory?

Would I need to implement a linked list/pointer structure (DVR, single element quueues, or similar) so that a Loop's children array is an array of pointers, or would this be managed by LabVIEW?

  

[tst · Accepted solution]

The object itself, if memory serves, is simply a pointer, so an array of objects *should* simply be an array of pointers, which is negligible. This article should have the details - http://zone.ni.com/devzone/cda/tut/p/id/3574

Also, if you do want a linked list, there should be some implementations available. Try searching on LAVA or in the Lapdog group here.

[yenknip]

Thanks very much tst, that article was great. For anybody else looking for info, the section named "What is the in-memory layout of a class?" holds the answer.

Regarding linked lists, I successfully made a linked list in a previous project, based on the ideas here, 

[Mark_Yedinak]

---

@tst wrote:

The object itself, if memory serves, is simply a pointer, so an array of objects *should* simply be an array of pointers, which is negligible. This article should have the details - http://zone.ni.com/devzone/cda/tut/p/id/3574

Also, if you do want a linked list, there should be some implementations available. Try searching on LAVA or in the Lapdog group here.

---

I don't think this is entirely true. LabVIEW objects are "by value" and therefore you cannot simply have pointers to them. The article you posted stated that all instances of the same class can share a single copy of the default data (a.k.a a pointer to a default instance of the class). Once you modify any data you get a new copy. I don't think an array of the classes will not simply be an array of pointers to the those instances. Hopefully Stephen Mercer can chime in with the definitive answer.

[yenknip]

I was specifically looking for information on how objects are stored in memory, and whether I would need to explicitly define non-concurrent memory addresses for a large data set. I am aware that they are not 'LabVIEW references/pointers' in the same way as the synchronisation palette items, and that splitting the wire will create 2 copies of the LV Object

[AristosQueue (NI)]

---

Mark Yedinak wrote:

I don't think this is entirely true. LabVIEW objects are "by value" and therefore you cannot simply have pointers to them. The article you posted stated that all instances of the same class can share a single copy of the default data (a.k.a a pointer to a default instance of the class). Once you modify any data you get a new copy. I don't think an array of the classes will not simply be an array of pointers to the those instances. Hopefully Aristos Queue can chime in with the definitive answer.

---

When you say "array of the classes" you mean "array of the objects". Terminology matters. 🙂 An "array of the classes" would be an array of library refnums.

Yenknip's conclusions are correct. An array of objects will be an array of object pointers, laid out in a block, exactly like they are described in the linked white paper. Behind the scenes, the copy-on-write mechanism takes care of unsharing the default data pointer as needed. Forking the array will deep copy all the pointers.