Why labview would allocate more memory in every run?

[Arroyo]

Dear all, 

I have been working with big images in LabVIEW for some time and started to have some memory usage  problems. 

The problems got worse when I packed my code segments in smaller subVIs. I suppose the compiler creates additional copies of the image arrays for all interfaces within the SubVIs.

That seems to make sense. What  I still do not get is why would the compiler allocate more memory everytime I run my code (same image, same parameters). As far as I understand, that should take the same memory everytime (which is allocated by the compiler in the first execution). However, I see  every time the code finishes execution how the use of memory is slightly higher (about 10-20 MB more).

Do you know, which could be the typical reasons of such a behaviour? 

After the execution of my code, I´m deallocating the memory taken by the images and opened IMAQ sessions. I also tried with Request Deallocation but same results.

Slightly better results were observed if I call the SubVIs by reference (dynamic calling), but the increasing memory usage can still be observed. 

I would appreciate your help.

Thanks,

Esteban 

[James.M]

Are you closing your references?

Sharing your code would help debug this as well because there might just be something you're overlooking in there somewhere.

[Arroyo]

Hi James,

Thanks for your answer. Yes I´m closing the references.

Unforntunately for confidentiality reasons I can´t share the code here. My question was directed to people having similar trouble, i.e. an increasing use of memory in every run. 

I though there might be a set of reasons explaining that behaviour and perhaps some of you guys could mention them. I would then verify the code against this possible reasons to find the source of the problem.

Best regards,

Esteban

[PeterFoerster]

Well as James already pointed out: At some point you are not freeing some resource while at the same time allocating a new one. Having the same issue is not that easy to determine: You might be having the same issue for entirely different reasons.

Can you dumb down your VI enough to share it here? Does the problem still persist after you reduced code?

[Ben]

This tag could is cross-linked with my tag "LabVIEW_Memory".

I suspect one of those threads hold the answer you are looking to find. "There is nothing new under the sun." (Eclesiasties)

Ben

[Arroyo]

I'll check the thread, thanks.
I have been using the profile/memory tool for debugging. Unfortunately there I can just see the memory used by the VIs. Is there a way to see the memory usage of the VI's variables? In this case I could see which variable (e.g. array or cluster) is getting bigger in every run. Any idea?
Regards,
Esteban

[Ben]

Somewhere in that Tag Cloud I linked you should find at least one mention of "Profile >>> Show Buffer allocations".

There is also the option of desk top Execution trace tool that will tell you every little detail.

Ben

[Hooovahh]

Asking to debug your code without seeing it is like asking a mechanic to fix your car without brining it to him.  Not much we can do but make guesses.

LabVIEW 2014 SP1 added a new feature for Profileing buffer allocations Tools >> Profile >> Profile Buffer Allocation.  I haven't used it yet but it looks neat and might help find memory allocation.

[Ben]

---

@Hooovahh wrote:

Asking to debug your code without seeing it is like asking a mechanic to fix your car without brining it to him.  Not much we can do but make guesses.

LabVIEW 2014 SP1 added a new feature for Profileing buffer allocations Tools >> Profile >> Profile Buffer Allocation.  I haven't used it yet but it looks neat and might help find memory allocation.

---

Thank you for teaching an old dog a new trick.

Ben

[k.huber]

Hi Esteban,

have a look at the following link:

Memory Management for Large Data Sets - LabVIEW 2012 Help - National Instruments
http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/memory_management_for_large_data_sets/

Altough it is pretty old (2012) the included guidelines might still be useful to you.

Best regards

Kathrin