clear arrays pragmatically

[altenbach]

---

@Arroyo wrote:

PS: I´m not pretty sure how to dispose the images.  

---

• The subVI you show is not reentrant, so there is only one copy in memory. Assuming that the images are all of the same size, it will re-use the same memory for each processing call and nothing should grow as a function of the number of images and you should not even need to worry about the memory used. It only represents the memory for one single image overall.
• If you actually use "request deallocation", you are making things much worse because the memory needs to be reallocated from scratch with each call. You might get serious memory fragmentation. There is a good reason why LabVIEW is relatively lazy deallocation memory because chances are very high that the same amount of memory is needed at a later point again. There are very few scenarios where this is not desirable.
• You should also disable debugging on the subVI.
• As has been mentioned, make sure that the front panel is not in memory (front panel closed, no unsaved changes, etc.)
• What is your evidence that the shown subVI is the cause of the huge memory consuption? Are you using DETT to debug?
• How involved is the image processing? Is there a lot of code and other subVIs? How big are the images?
• I think you need to present better evidence that the shown subVI is actually the source of all of your problems. personally, I doubt it!

[Arroyo]

Thanks for your detailed answer.

My subVIs contain several other SubVIs  and execute many IMAQ operations within loops. Some copys of the images are created within the process in order to prevent destructive operations such as IMAQ Extract from affecting the images I have wired as Shift Registers. I try to dispose every image after it has been used.  Images are quite big, in the order of 7000X3000 pixels. 

I belive my main problem is to convert everytime arrays to images and viceversa. Each SubVI must do these actions.

When I open LabView it consumes 150MB. During the first execution the memory consuption reaches a peak of 1,6 GB and when the exceutions has finished, it remains at 1,2 GB.

During the second execution, the program starts at the 1,2 GB reaches 1,61 GB and ends up at 1, 21 GB, approximately. I have a memory leak of 10 MB in every iteration. Still haven´t figure out where.    

I will disable the debuging mode, and close the front panel to see how perfoms. 

Best regards,

Esteban

[karthickkece]

I faced this same issue in other application  of reading an large excel sheet and processing the array, I got no solution for it, but when i created the exe it works fine everytime the memory consumption goes back normal. so, try buiding exe and check once.

[Eric1977]

I don't understand why you are converting arrays to images and vice versa. I am assuming that you alreadty have some image that you are trying to process (the 7000 x 3000 pixel image). Why are you converting this back and forth? Seems like there is unnecessay processing taking place. It's REALLY hard to diagnose this without your VIs and SubVIs.

[Arroyo]

The reason, as stated before, is a requirement for the future integration of the SubVIs in a .NET solution. 

[James.M]

The pragmatic way to resolve this post would be to create a VI, or set of VIs, that recreate your memory issue. All of these lovely forumers could then recreate the issue and help you solve it from there. Commonly, performing this step will lead you to your solution on its own.

[Gregory]

If you do post an example, try to include some standard data with it. You can do this by running the VI once and either create a constant on the indicator that holds the 2D array, or click "set as default" on the control that took the input data.

[Ben]

If the same 2d array is being passed to each sub-VI...

Crate an Action Engine with a method "Load data" which will place the 2d array in a shift register.

Crate actions for each sub-VI you have now and put the processing of the sub-VI in the appropriate action case.

TO start out I would NOT crate sub-VIs inside the action engine to do the number crunching.

If you code that AE right, the 2d data should sit in-place one shift register and not be duplicated.

If you get past that hurdle, then sub-VI can be created bu be sure to wire the 2-d wire through the sub-VI as described in the "Clear as Mud" Thread so that the sub-VI work in the SR buffer.

Ben

[altenbach]

---

@James.M wrote:

The pragmatic way to resolve this post would be to create a VI, or set of VIs, that recreate your memory issue.

---

Thanks, I was trying to bring in pragmatism, but I think the OP was thinking of a different word. 😄

[James.M]

---

@altenbach wrote:

---

@James.M wrote:

The pragmatic way to resolve this post would be to create a VI, or set of VIs, that recreate your memory issue.

---

Thanks, I was trying to bring in pragmatism, but I think the OP was thinking of a different word. 😄

---

It's problematic that OP used "pragmatic" instead of "programmatic" and his code tactic is mystic because he can't share it. The forum should also be more emphatic regarding title veracity to predicate specific search query quality.

(I spent way more time on thesaurus.com than I'm willing to admit. )