memory issue LabVIEW won't deallocte

[AustinPeter]

Hello,

I was wondering if anyone could help. I am running LabVIEW 2012 and playing with manipulating data from a reasonably large file 40Mb using a lot of String Arrays.

Everything runs ok, the problem I am having is that everytime I run the VIs associated with the program, even when I shut them down LabVIEW is keeping them in memory, so my Ram usage is going up to about 3GB each time and I cannot get it to reduce without shutting down LabVIEW which is reallly started to prove frustrating. I have put in a few de-allocation elements but that doesn't seem to be solving it. I was just wandering if anyone know a magic command to deallocate all VIs in LabVIEWs memory without me having to shut down completely.

I know I could make the whole thing more memory efficient by not using String arrays and instead just using a single string but that is not the problem as each VI individually handles it fine and I dont have any indicators on my top level VI which would be holidng it up?

Any ideas welcome.

Thanks!

[Yamaeda]

It sounds to me like you're creating data copies, making it hard for LV to keep track and deallocate. Could you post the VI's?

/Y

[altenbach]

Do you have uninitialized shift registers or feedback nodes?

---

@Develop-inG wrote:

I have put in a few de-allocation elements but that doesn't seem to be solving it.

---

What is that? Are you talking about the "request deallocation" primitive?

---

Develop-inG wrote:

Everything runs ok, the problem I am having is that everytime I run the VIs associated with the program, even when I shut them down LabVIEW is keeping them in memory, so my Ram usage is going up to about 3GB each time and I cannot get it to reduce without shutting down LabVIEW which is reallly started to prove frustrating.

---

How are you "shutting down" VIs? Closing a front panel does not shut anything down. Are the front panels of subVIs open or closed? Do they contain primitives that force the front panel into memory even if they are never opened?

I would really like to see some code.

[AustinPeter]

Hello,

Yep I am talking about the request de-allocation function.

I have attached some code snippet. There are multiple VIs like this, I have squeezed this one into one screen for the snippet hence starts at the top and works its way down.

Thanks!

[AustinPeter]

Can you also expand on the primitives part. 

I dont think that there should be anything that stays in memory.

I have one cluster that gets updated in each VI and the data passed through. I will attach the snippet of the top level VI

One thing that strikes me as strange is I shut down every single VI so that only the labVIEW splash screen is there and i still have 2.5GB of RAM used by LabVIEW

Thanks!

[altenbach]

Sorry, I will have to study this later, but just glancing at it shows quite a few questionable things:

in snipped.png:

• the "time taken" will most likely show always zero, because both frames execute in immediate succession, in parallel to the rest of the code. what is the purpose?
• reshaping a 2D array to a 1D array could be done with the "reshape" primitive. Doing a sucessive "array to spreadsheet string" followed by "spreadsheet string to array" seems very Rube Goldberg. 
• The entire code is a constant dance between different representations (1D array, 2D array, cluster, cluster array, spreadsheet string, etc.) Are you sure this could not be done a bit simpler?

In snippet 2.png:

"request deallocation" does not care about execution order, so placing it inside a sequence frame is meaningless.

[AustinPeter]

Ok, Please keep me posted when you have some thoughts on the overview with regards to the memory issue overall. You mention that the VI wont leave memory even though I have shut down both the front and block diagram. All I want is to get a way for it to leave memory when it has finished running or the front diagram has been shut down. How do i make that happen?

Thanks for the code review 🙂 I thought I would send you the worst VI so you can see the amount of indicators etc and number crunching each VI does so please dont worry about the indivuals, the code works perfectly for what I need and is a resolution of different features hence the different conversions is due to previous merges.

ie. time taken is a debug tool i use when i need a timer of two instances, so isn't currently being used. This particular vi is mainly a rip from the 2D array sort VI hence the changes around and yep I am sure it could be done simpler now its finished. For snippet two. I wanted to demo that, would it be useful to have that in every VI, ie. would that solve the problem I am having? I can imagine not.

Thanks and look forward to your response! 🙂