LVOOP: Objects sizes

Question

Hello
I have few questions regarding LVOOP. I'll be refering to this whitepaper: http://www.ni.com/white-paper/3574/en, especially the part where it says:
LabVIEW allocates a single instance of the default value of the class. Any object that is the default value shares that pointer. This sharing means that if you have a very large array as the default value of your class there will initially only be one copy of that array in memory. When you write to an object’s data, if that object is currently sharing the default data pointer, LabVIEW duplicates the default value and then perform the write on the duplicate. Sharing the default instance makes the entire system use much less memory and makes opening a VI much faster.
Now, let's say I want to create class hierarchy, which is defining the behaviour of some other class (a Strategy pattern). No class in the hierarchy contain any mutable data, they're only redefining some methods. I've visualized this in the following picture:
Project with this VI is in the attachment.
So, here are the questions:
What is the size (in bytes) of LV Object? Whis question can be splitted into two: what is the size of actual object, which is stored somewhere in memory, and what is a size of a pointer to this object?
If I create class, which has no data, just some methods, what is the size of the object of this class? According to the whitepaper fragment above, there should be only one instance of this class in the whole application, and everything would point to it.Therefore the answer to this question would be exactly the same as the answer to question 1?
Folowing question 2: if the class methods are not reentrant, there is also one and only one instance of each in the whole memory?
And all of this leads in fact to single question: if I use such pattern, I only "pay" once for allocating all my "Worker" objects in memory, and then LV simply reuse them?
Solved!
Go to Solution.
Attachments:
ObjectSize.zip ‏100 KB

Answer 1

PiDi wrote:
So far I understood that if I don't mess with the class data in any way other that reading it*, LV won't create another instance of data for this class objects (at least on desktop, RT is my main concern now). And this is useful information, especially if I want to create hundreds, maybe thousands of objects of the same class in my application.
On desktop, you're correct. All the wires will point at the single default value.
On RT, the instances are independent, but that doesn't mean you're ever creating hundreds or thousands of the same object. If you created an array of 1000 objects, yes, you would have 1000 instances. But if you forked one object wire to two different accessor functions, and neither of them modified the object, they would both be sharing the same object.
Everything that follows is a rough guess because the LV compiler is at this point smarter than any human at doing this analysis and I reserve the right to yield to its computational superiority. I did not take the time to construct your example and put it under a debugger.
More important safety tip than that: Everything below is true only of LV 2012. The compiler and its optimization systems were massively different in 2009, slightly different in 2010, somewhat different in 2011, and should be vastly different in 2013.
In the picture shown:
When you first hit the run button, there are 4 objects on the block diagram, one in each of the four constants. The Action object has a worker object inside of it (its default value). I am ignoring anything on the front panel on the assumption that if you were using this in an application the panel would be closed.  Total: 5
After section A, there are 6 objects of each of the Worker classes (5 in the array and one in the constant) and 1 Action object (in the constant) and another worker object inside that. In this particular case, I think that toggling debugging has no effect on the count, but in many cases, any interim steps would evaporate when debugging is turned off. Total: 20.
Running B will copy each element of the array into the Action object, leaving the array behind. Shouldn't those objects be moved into the property node? No. LV leaves the array in place -- it is already allocated if this entire VI gets called a second time as a subVI. So you now have 34 worker objects and 16 Action objects. Total: 50
C is curious... C will not make any further copies of the Action objects as it runs, but because you used the Property Node, you're guaranteed to make a copy of the Worker object when you read it. Because the property VI will only conditionally fire based on the error cluster, the property VI forces a copy. An unconditional VI call may or may not make a copy, depending upon many many factors, but mostly depending upon what happens downstream. Since you say that the square region would be done inside a method of Action, put that inside an Inplace Element Structure and use the Unbundle/Bundle pair and you remove the guarantee that there will be a copy made. There might still be a copy depending upon what you do in that subVI, but the probability shifts in your favor. I can't think of a scenario where an unmodifiable object would be copied going into a local subVI call (even if the subVI is reentrant or dynamic dispatch) but the LV compiler might know of a case, so I won't rule it out -- there might be something involving UI thread priority or something weird that I haven't thought of.
BUT, there will only be one object at a time, so after the loop runs, there will only be 51 objects total -- that new one is the final copy made inside the loop which remains allocated. 50 if you switch out for an inplace element structure.
When you call this subroutine a second time, those allocations are already made, and they get reused. So assuming you use the inplace element structure, there is not a continuous memory bloat when you call this multiple times in succession -- your memory level holds dead flat.