10-28-2015 05:17 PM
I am currently working on a data analysis application in which we have “out of memory” issues.
I have implemented all the "best practices" in the code with limited success.
The application does not use the best architecture to handle large data sets but it was the fastest development path to meet some of our deadlines. With the data set sizes we are currently processing, I had hoped to get away with it, and we did for a while!
Presently, the data being analyzed is completely loaded from binary files into a waveform array. The data set represents about 110MB of memory: 262144 samples x 52 channels x 8 bytes per double precision floating point value.
The memory issues started to appear when several file export options we added to the application. At that point, I realized that big chunks of memory were reserved and never being released after calling different functions (CSV file export, binary file export etc…) sequentially with the data set.
I have been searching for a way to deallocate ALL memory used by a subVI after its execution but I was not successful to date.
I have tried the following:
I am including some test Vis to demonstrate want I am talking about.
Main.vi is a small VI which calls the Function1.vi and Function2.vi upon a button press by the user.
Function1.vi is a VI which generates an array of 2MB and writes it to disk. No inputs and no outputs, except to disk.
Function2.vi same as function 1 except it generates a 4MB array.
1 - When starting Main by double-clicking on it, it starts to run and when all LabVIEW background loading is complete, the amount of memory taken by LabVIEW stabilizes at around 95MB (from task manager).
2 - When the Function 1 button is pressed, memory used by LabVIEW rises to 220MB (an increase of 125MB from step 1).
3 - When the Function 2 button is pressed, memory used by LabVIEW rises to 487MB (an increase of 267MB from step 2).
4 - When the Function 1 button is pressed again, memory used by LabVIEW drops to 417MB (a decrease of 80MB from step 3).
5 - When the Function 2 button is pressed again, memory used by LabVIEW rises to 487MB (an increase of 80MB from step 4).
Steps 4 and 5 repeat if the function buttons are pressed again.
At this point, LabVIEW is taking about 400MB more memory compared to when Main had not call the Funcrtion1.vi and Function2.vi.
Is there any way to release all resources (all memory) used by a subVI once it as returned to its caller VI?
Thanks for any help!
Michel Lanthier
Solved! Go to Solution.
10-29-2015 02:29 AM
Hi,
Try This, think will help You
Only configure in Main.vi subVIs paths. and inside subVIs give file path wher will be stored date
With Best Regards
10-29-2015 02:36 AM
While i see through your vi's, what version of LV are you using.?
There is this block that will help you release un-used memory allotted to a VI available on LV 2012 & above.
Quick search for "Request Deallocation" or find it in the Application Control Pellet > Memory Control > Request Deallocation.
Regards.
Digant Shetty (LV 18.0)
AE, Combined Digilog Systems Pvt. Ltd.
10-29-2015 08:07 AM
I am using LV 2013, service pack 1 (13.0.1f2, 32-bit)
Michel
10-29-2015 08:26 AM
For LV2013
10-29-2015 08:39 AM
Michel,
I'm assuming you do not know LabVIEW, and haven't viewed any of the LabVIEW Tutorials such as the ones listed in the upper right hand corner of the Forum home page.
Here are some observations:
I'm guessing that having only a single function and getting rid of the Express VI and Dynamic Data will have a dramatic effect on your memory allocation. Give it a try, tell us how it went.
Bob Schor
10-29-2015 10:42 AM
Thanks Hachya. This can probably be a solution for me.
Let me add one more thing: what if I needed Function 1 and Function 2 to receive some input parameters?
Michel
10-29-2015 10:53 AM
@Bob_Schor wrote:
Michel,
I'm assuming you do not know LabVIEW, and haven't viewed any of the LabVIEW Tutorials such as the ones listed in the upper right hand corner of the Forum home page.
Here are some observations:
- Function 1 and Function 2 are the same function. They create an array of data parameterized by a Size and a Content, and the results are written into a TDMS file with a specific File Path.
- Write this function with the following inputs: File Path, Data Size, Test Value, and Error In. Wire these to the left-hand 4 connectors. Wire Error Out to the bottom right.
- The function should not use an Express VI (they are wasteful of resources), and should not use Dynamic Data. Use the TDMS functions from the File Palette. [Why are you using TDMS? Have you thought about the File Format?].
- The Error Line should be used to sequence your functions within this sub-VI.
- In your Main, get rid of the Stacked Sequence! Once you have the Error Line, you can simply line up Function 1 and Function 2, sequence them with the Error Line, surround each with a Case Statement guarded by your two Booleans, and there's your program.
I'm guessing that having only a single function and getting rid of the Express VI and Dynamic Data will have a dramatic effect on your memory allocation. Give it a try, tell us how it went.
Bob Schor
Bob,
Thanks for your reply.
I do have some experience with LabVIEW.
Main.vi, Function1.vi and Function2.vi are just an example I built so that I can find a way to get rid of ressources used by a subVI after its execution, in the scope of a much larger application.
I never use Express Vis unless I need to do something quick and dirty. However, in this case, they provided me with an easy way to illustrate the problem I am trying to fix, that is, releasing memory ressources after a memory hungry subVI executes.
10-29-2015 11:08 AM - edited 10-29-2015 11:09 AM
Your example is very poor, because the code only depends on diagram constants and is thus precalculated at compile time (folded). The data is part of the code! As long as the main VI is in memory, the subVIs will be in memory.
Please show us the actual code that is causing you memory problems.
Just from looking at your code, I suspect that you are a beginner so there are problably tons of inefficient constructs. Most likely, your memory problems are non-issues.
Don't use stacked sequences. Stay away from dynamic data and express VIs.
10-29-2015 11:26 AM
Welcom Michel!!!
If You will need help write me.
With Best Regards
Hrachya