Ideas to release the memory associated with Dynamically Instanciated Objects

[drjdpowell]

---

@Ben wrote:

LabVIEW as designed by Jeff K freed the developer of the mundane tasks of malloc etc. but due to LVOOP missing "Destroy" we are again forced to think about the envirnment again.

---

Why do you single out LVOOP?   It follows the existing LabVIEW design of any other by-value datatype in leaving it to the compiler to handle memory deallocation or reuse.  It is not well suited to cases where a large fraction of computer memory is used by one by-val instance; but having an explict destroy method wouldn't fix that issue very well, as you'd still have to be very careful about anything that may make a copy, like a terminal, or a probe, or an indicator.  Just opening the front panel of a subVI or clicking "retain wire values" would crash the computer. Switching to by-reference data of some kind seems reasonable for 1 GB data sizes.  

[Norbert_B]

Before firing things about by-val vs. by-ref on a knight of NI, we should question the situation as is. So here are some feed for thought:

1. Are you sure that each game individually runs properly by itself, even if called from the top-level application (what you called the "While loop")?

2. If each game run by its own, is something of the game stored in the caller (aka the "While loop") which could result in LV keeping the memory for the game instance?

3. Does running a single game several times create the issue aswell or does the out of memory require the caller to swap games?

Norbert

[Ben]

---

@Norbert_B wrote:

Before firing things about by-val vs. by-ref on a knight of NI, we should question the situation as is. So here are some feed for thought:

1. Are you sure that each game individually runs properly by itself, even if called from the top-level application (what you called the "While loop")?

2. If each game run by its own, is something of the game stored in the caller (aka the "While loop") which could result in LV keeping the memory for the game instance?

3. Does running a single game several times create the issue aswell or does the out of memory require the caller to swap games?

Norbert

---

Maybe you should.

My harping on the destroy is the answer my OOP trained co-worker keeps desiring.

So If I created a DVR with a data type of the parent Game and pused in a "Monopoly" child I get from a factory pattern the invoke a "Play Game" method on what is the DVR...

and then close the DVR

Will LV dealolcate the resources associated with the Monpoly Instance that was in the DVR?

If so this may be the pattern I am looking for but the message just never got through my thick skull.

If true I'll pass this along to my co-worker and let him try it out.

Trying to learn,

Ben

[Norbert_B]

Ben,

a DVR on an object is just the same as a DVR on a cluster. Is the memory of the cluster freed once we destroy the DVR on it? Maybe...maybe not. The LV memory manager decides that.

That being said, it *could* make a difference on the status quo... but if implementation is done properly, there shouldn't be a difference.

Norbert

[Ben]

"Maybe...maybe not."

And I find myself back where I started.

In UML a SSD (System Sequence Diagram) uses a Life Line that has a begining when the object comes into existinace and and posibly an end where the object goes away.

I appreciate your thoughts and time greatly. I pass the DVR experiment to my co-worker the next time I hear him utter is mantra.

Ben

[JÞB]

---

@Ben wrote:

"Maybe...maybe not."

And I find myself back where I started.

In UML a SSD (System Sequence Diagram) uses a Life Line that has a begining when the object comes into existinace and and posibly an end where the object goes away.

I appreciate your thoughts and time greatly. I pass the DVR experiment to my co-worker the next time I hear him utter is mantra.

Ben

---

And post back with observations.  Be specific about LabVIEW versions.... I think I heard a clue about LV memory manager smarts

[Ben]

---

@JÞB wrote:

And post back with observations.  Be specific about LabVIEW versions.... I think I heard a clue about LV memory manager smarts

---

Since you asked, I will.

But don't hold your breath. Since we know "there be dragons there" we avoid those regions and only dip our toes in the water when pushed.

Ben