De-allocate memory after execution of main application

[Elamaran]

Hi All,

My application (Exe) takes 5MB on system RAM when it is just launched (will be in idle loop). It executes test cases that are available in an Excel file, upon a button press, and goes into idle after completing the execution. During test execution it collects lot of data from instruments and processes it. Everything looks fine till now.

The problem is, after the execution it holds around 250 MB of RAM because of the data handled during the test. So I am trying to figureout a way to deallocate all unused memory related to the application.

Note: I know about "Request Deallocation" LabVIEW primitive. To make use of it I have to place it on all subVIs to deallocate memory at the end of execution. Even then memory allocated in my main statemachine will remain allocated.

I need to deallocate those memory and bring it to the state of '5MB initial condition' as mentioned above.

Please share your ideas.

[GabbyG]

Hello

Can you please explain more about the test cases. Are these EXEs as well ? Then they should close without a trace.

You can try to start any sub-vis with dynamic call. That will also unload any memory after completion.

One more thought. Does the 250 MB build up after several tests in sequence. If not, the memory manager will re-use the allocated memory.

250 MB is not really much. 😉

Gabi 

[Yamaeda]

If you have 250Mb of data you must have some large arrays, empty them by wiring empty arrays and if memory doesn't lower, use the request deallocation.

/Y

[Elamaran]

Hi Gabi,

Thanks for your comments.

I have only one Exe which is my applicaiton. It executes multiple test cases specified in multiple rows of an Excel sheet by parsing them one by one.

The use case of my application is as following,

1. User will load an Excel sheet, for example with 10 test cases, and hit 'Run'.

2. Application will the read the Excel and execute all 10 test cases one by one. 

3. Then it goes to idle mode where it will just loop with some Wait time.

Again the user might come up with 20 new test cases in an Excel and run it.

So while executing the test cases, it initializes multiple arrays, captures and processes waveforms. This is what taking up huge space in RAM. I know these facts well.

I have around 200 SubVIs so I cannot dynamically call everything. But what I am thinking is that I should try few selected VIs which I know are memory consuming VIs.

That much memory allocation is required for very first Test case itself, which means memory is not keep on increasing but reused. The concern is after executing all the tests how do I release those initialized memory.

[Elamaran]

Hi Yamaeda,

Thanks for the comments.

I have tried connecting empty arrays but it doesn't seem to work. Or I need to spend little time on it. 

Request Deallocate won't have effect on running VI.

[Yamaeda]

---

@Elamaran wrote:

That much memory allocation is required for very first Test case itself, which means memory is not keep on increasing but reused. The concern is after executing all the tests how do I release those initialized memory.

---

Once you're done testing and shut down LV it'll release memory. Are you running on a low memory system?

/Y

[Elamaran]

Hi Yamaeda,

I think you didn't go through use cases my application clearly. It says, when my application finishes exectution and goes into idle state it has to release the memory. Not that it has release when it is getting closed(that will happen and the OS won't let any closed application to hold memory on its RAM)

[altenbach]

If the program is kept running, I don't see why you even want to release the memory, because it would need to be reallocated on the next test, leading to more memory fragmentation. If there are no more test, close the program and the problem is solved too.

If the tests are done in subVIs (as they should), you could call "request deallocation", and the subVIs will release the memory each time they finish. (Again, this might not be a good option, since they need to allocate about the same amount of memory on the next call anyway. It is more efficient to hold on to the memory between calls, right.)

So what is your main concern? 250MB is not much for a modern computer, in fact it is probably less than 10% of the total RAM. Why worry? Do you have performance issues?

[Elamaran]

Yes, I agree with your point. It is not good to deallocate and allocate it again. Also 250MB is not a big deal.

Initially I wanted to do it and I couldn't find a way. Though I may not use it, I still feel that it is good to explore little bit. 

Thank you anyways.

[Ben]

LV attempts to help out by managing your memory in your behalf. As already noted above, allocating is something that should be avoided so LV will allocate and keep memory. It will not give it up until all chances of reusing that memory are gone i.e. when the app exits.

You could implement you "test" as a VI that is dynamically called executed and then closed. When the dynamic VI is clsoed its resources will be released and the memory freed up.

But that is a last ditch approach that I call on only when I can't "do it right". By doing it "right" I am refering to constructing your code such that it re-uses memory buffers by working in-place with all large data strucutres. DVR's can help you "work inplace" as well as Action Engines.

If you are intersted in reading more about performance issue in LV I suggest you look over the threads linked in this Tag Cloud where I have collected links for a lot of very good threads discussing performance. If you give those thread a good study and take the time to understand the issues you will be well on your way to becoming a LV Performance master.

Have fun!

Ben