05-21-2013 07:27 PM - edited 05-21-2013 07:29 PM
Background:
I am working on a compact field point and am sensitive to memory usage.
I would like to know hoe the labview Realtime compiler treats my code (It is a bit of a Black Box.
My Class contains other objects:
and then later in my code I use what I call Run Loops: Multiple Parallel loops executing various threads: Below.
It also calls some of the classes Ancestor objects:
My question is: does this approach make a second copy of the embedded(Included) objects.
If so does anyone have any clever ideas about how to avoid this?
Thanks in advance.
iTm
05-21-2013 07:42 PM
P.S. I have considered using Object references instead but it does tend to kill off the polymorphic goodness that that OOP Gods have given us.
Now.. if the references would polymorph like regular objects, that would solve a lot of problems.
05-22-2013 01:35 AM
I have no real answer to you, because I generally don't concern myself with if copies are made or not, but I would suggest reading this thread, which might help - http://forums.ni.com/t5/LabVIEW/LVOOP-Objects-sizes/m-p/2134884/highlight/true#M691422
In general, objects follow the same rules for data copies as everything else, so it looks like you will get at least one copy where you split the wire in the beginning. I don't see any other obvious ones (other than that each accessor you use to take an object out of your main object will generate a copy), but I didn't look too closely.
05-22-2013 01:58 AM
tst,
Thanks for the Link, And the response.
In the spirit of sharing ideas, if my application wasn't a pyramid of classes, it would be an easier solution:
--------------------------------------------
Use in-place structures, that way they won't be copied
The hearteache is that when you do that, you lose access to the parent data and functions.
--------------------------------------------
Plan "b" is to convert the embedded objects to Refnums, That way only the Pointer is retained by the parent class.
The Drawback is that they can be painful to code as a Data value reference read is required for each thread and may only be used from within the object. Refnums don't polymorph easily
I have also unearthed some very odd compiler behavior.
iTm L
--------------------------------------------
Plan "C" is to "Check out" the Object replacing it with a default. and hope the compiler doesn't allocate memory for it.