LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Anxious Memory Deallocation

Solved!
Go to solution
I am using LV v7.1 and had a memory problem I solved with the Deallocation function. However, I would like to use the Anxious Memory Deallocation that used to exist as an Option. I don't see it in LV7.1. Can I still put the switch in the INI file or is that no longer possible. That is, am I now forced to live with a default of NOT ANXIOUS so I have to use the Deallocation function? or can I change that in an INI file?
0 Kudos
Message 1 of 9
(5,796 Views)
Solution
Accepted by Antipholus
National Instruments discourages the use this option. It may free up a little memory after each subVI has been run, but it dramatically decreases overall performance. Because of this, the option has been removed from LabVIEW 7.x and the ini token no longer works. The deallocation function is still available for those cases where it is absolutely necessary. Hopefully this will not cause you too much of a problem.

Have a great day!
Robert Mortensen
Software Engineer
National Instruments
0 Kudos
Message 2 of 9
(5,772 Views)
This just help others who find memory allocation and realeasing an issue.

Background:

LV 7.0

Main VI calls one of four tests.

Each called tests used a lot of memory to display acquired data.

Each called test would allocate about 220M of memory to handle the displays when they were run.

Writing empty arrays and histories did not release the allocated memory.

When each test was completed, its FP was closed but was still part of the "mains" hiarchy.

Running all four, one after the other, would always fail because of insufficient memory!



New approach:
At the end of all of the test VI's I dropped an

Advanced >>> Data manipulation >>> Request Deallocation

function and wired a true boolean to its input.

I then removed the Test VI's from the Main and used proprty nodes to control the FP visability and used an invoke node "Run VI" method set for "wait until done".

Using the above method DID slow down the opening of the test VI from the main
BUT
It returned the 220 M of memory that was getting allocated and never returned.

I hope this helps,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 9
(5,720 Views)
I'm facing a memory problem as well, I'm doing 12k sampling and 4096pt FFTs on 16 channels, and checking the results against limits and so on and I'm getting memory issues, I rad the application note 168, Performance and Memory Management and it spoke about "request Deallocation" (as well as other methods of reducing memory usage).

unfortunaly my programming is being done on a separate standallone PXI system and I can't easily show you what i'm doing but I'm essentially got two subVIs (spectral analysis.vi and my own subVI that works out averages and compares results with fault levels) that are run every iteration of the main loop when new data is available and two other subVIs record information when faults are found.

I've do have information being displayed to the FP but its not critical to the application and essentially for me to see that everying this working correctly.

So my question is when is it appropriate to use the request deallocation funtion, the two function that run each iteration chew up a fair bit of memory but I'm assuming that if memory is deallocated each iteration then it is going to have to be reallocated as well, is this correct? what do you suggest for the best outcome.

Cheers

Andrew
90% of all experts aggree that 1 out of 10 experts are wrong
0 Kudos
Message 4 of 9
(5,600 Views)
"
So my question is when is it appropriate to use the request deallocation funtion, the two function that run each iteration chew up a fair bit of memory but I'm assuming that if memory is deallocated each iteration then it is going to have to be reallocated as well, is this correct? what do you suggest for the best outcome.
"

Your expressed understanding is correct!

The deallocate approach is good if you have something that is done very infrequently, requires a lot of memory.

I would use this if a customer wants to run a big report once a day or so.

Allocating memory is very expensive time-wise.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 9
(5,591 Views)
cheers mate
90% of all experts aggree that 1 out of 10 experts are wrong
Message 6 of 9
(5,568 Views)
 
0 Kudos
Message 7 of 9
(4,669 Views)

Hello  Member Antipholus ,

I am using LabVIEW 8.5 and are facing the memory leakage problem in the code developed by us.

The code constitutes a large number of Shared Variables (may be 300 in number). These Variables are residing in different moduled subvi's

I tried solving it by using deallocation function having a thaught that it will deallocate the memory use by the subvi and hence will lead to the better performance of the code.

But the problem of memory leakage is still there althrough we increased the virtual memory.

One more point i want you to know is that the PC on which the code is meant to be executed is having 1GB of RAM.

 It may be possible that i didn't used the Request deallocation properly but i read the description and it has been clearly written in the description that this function will be of great concern with the applications like a main VI and a number of Sub VI's.

I placed this function at the end of each subvi and a true constant has been wired to the input flag whenever the user clicks to exit the displayed front panel of any subvi which he has opened from the Main Panel.

We are in uncertanity that what factor is leading to memory leakage. 

I also read a document in the discussion forum that if a number of build array function is used in a continuous loop it can cause this problem and the solution in this regard is to replace build array function with replace array subset as the number of indexs will remain same.

We also done this and replaced the build array with the suggested function but the problem still remains.

 

Can you please suggest any possible solution.

 

Thanks & Regards,

Samriddh Sarbalhi

 

0 Kudos
Message 8 of 9
(4,666 Views)

Hello Robert,

 

I am using LabVIEW 8.5 and are facing the memory leakage problem in the code developed by us.The code constitutes a large number of Shared Variables (may be 300 in number). These Variables are residing in different moduled subvi's I tried solving it by using deallocation function having a thaught that it will deallocate the memory use by the subvi and hence will lead to the better performance of the code.But the problem of memory leakage is still there althrough we increased the virtual memory.One more point i want you to know is that the PC on which the code is meant to be executed is having 1GB of RAM. It may be possible that i didn't used the Request deallocation properly but i read the description and it has been clearly written in the description that this function will be of great concern with the applications like a main VI and a number of Sub VI's.I placed this function at the end of each subvi and a true constant has been wired to the input flag whenever the user clicks to exit the displayed front panel of any subvi which he has opened from the Main Panel.We are in uncertanity that what factor is leading to memory leakage. I also read a document in the discussion forum that if a number of build array function is used in a continuous loop it can cause this problem and the solution in this regard is to replace build array function with replace array subset as the number of indexs will remain same.We also done this and replaced the build array with the suggested function but the problem still remains. Can you please suggest any possible solution? Thanks & Regards,Samriddh Sarbalhi

 

0 Kudos
Message 9 of 9
(4,665 Views)