LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LVOOP challenge question: How is Memory managed when objects are data members?

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:

Class.png

 

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:

 

Run.png

 

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

 

iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
0 Kudos
Message 1 of 4
(2,277 Views)

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.

iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
0 Kudos
Message 2 of 4
(2,271 Views)

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.


___________________
Try to take over the world!
0 Kudos
Message 3 of 4
(2,249 Views)

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.

 

iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
0 Kudos
Message 4 of 4
(2,244 Views)