How to deallocate memory after database fetch

[Oksavik]

Hello,

I'm experiencing memory leaks in my application, when I attempt to export larger amounts of data from my database (MySQL) using the Database Toolkit.

Basically, I'm making the query and fetch inside a SubVI ("Fetch Test.vi" in this example), and not unexpectedly this .vi will make the memory usage of LabVIEW.exe increase (as seen in the Task Manager).

If I close LabVIEW, the memory is released, no problem.

How should I proceed to make LabVIEW release the memory when the SubVI has completed execution.

I've tried calling the "Fetch Test.vi" from a different .vi ("Call Fetch.vi") and also including the "Request deallocation.vi" in "Fetch Test.vi", but the memory is not released.

Please see enclosed screenshot for this simple test.

How should I proceed to sucessfully release memory after the SubVI "Fetch Test.vi" has completed?

Thank you!

[Bob_Schor]

A comment and a question.

• If you could include some code (runnable VIs) that show what you are doing, we could try "variants" (or point out better ways) to try to "fix" the problem.  Having a (small) Database Sample would also help.
• You say "export larger amounts of data from my database".  It is not clear to me (and I can't look at the code to decide) whether the data is being imported from the database to LabVIEW or exported to the database from LabVIEW.

Bob Schor

[Oksavik]

Thank you for your reply.

Let me try to clarify:

The goal is to read data from the database and write to file. I've only focus on the reading here, since this is the part that causes memory issues.

I don't think I can share the database here, but it is a very basic structure.

ID, timestamp and about 100 columns of double values.

Size is about 20.000 rows.

Best regards

[Yamaeda]

LabVIEW handles the memory for you, since reserving memory from the OS takes time, it holds on to it in case you need it for other functions after the database releases it. Unless it grows uncontrollably it's as it should.

/Y

[Ben · Accepted solution]

You are SOOOO Close !

But what is missing is dynamically instaciating the VI that is doing the fetch. AS you have illustrated in your image, you are calling hte target VI using only its name. For that to work in an exe the VI must already be in memory.

The "deallocate" will deallocate when the VI in question is removed from memory as you have observed when you close the exe the memory is released.

So if you REALLY want get that memory back you will have to get the target VI out of your application and call it dynamically and then after it completes, close all references to it.

As previously mentioned, allocating memory takes a long time, so going the route of "I will force deallocation" you will be slowing things down. If the fetch is only done occationally, this may not be a concern. For the most part, LabVIEW management of memory is rock-sloid and LV is smart enough to re-assign allocated memory. This menas that you may see LV gobble up memory and not release it. Usually good for performance. I would only recomend "bending over-backwards" to deallocate if you need the memory and can not spare any.

Have fun!

Ben

[Oksavik]

Hello Ben, and thank you for the answer. I've settled for letting LabVIEW deal with the memory as it sees fit.

I just wanted to comment, that when I tested this I actually used the full path to "Fetch Test.vi", and not only the name as in the image.

I removed the full path, since I didn't think this made a difference, and it contained some information.

If you don't mind, how would I change my example to get the target VI out of my application and call it dynamically and then after it completes, close all references to it?

Assume that I have the full path when referencing the .vi already.

I've marked your answer as the solution, since I think this is what applies for most, but for the sake of learning, I would like to know.

Thanks again.

[Ben]

It has been years and things have changed since I did that...

If memory serves you will have to mark the traget VI as "always include" in your build but do NOT include it in your application exe.

Then use the resulting file spce to the target when you do your open.

I would have to fidle with it a bit to remind myself of the details of the Build, the installer, and the name-mangling of the VI as a stand-alone.

I would probabaly start looking at the set-up required for dynamically instanciating LVOOP classes sinc eth eapproach would be the same.

Ben