Do repeated Local and Global variable use in loops cause memory leaks?

[jim006]

I have a many-threaded VI where each thread is in a sub-VI.

I communicate between the VI's using events. I use global variable to store system wide configuration and state information.

I make extensive use of local variables to change indicators and readouts on the front panel. For example, to change an error light, I'll use a local variable for that boolean indictor and change it in my VI.

The main VI is heavily state-based so there's a lot of looping when moving through a large sequence of states.

When I run the VI, my RAM perpetually drops! I loose about 100 bytes per second. After 15 minutes or so all my physical RAM is used up and the computer bogs down with virtual RAM hard-drive
writes.

I don't know where to begin on tracking down the memory leak.

Is it possible that local/global variable usage is causing the memory leak?

How do I free memory for a local variable after a sigle cycle of a while-loop? Do I even need to do this?

Looking for some help.

Thanks!

[CoastalMaineBird]

The basic answer to "Do repeated Local and Global variable use in loops cause memory leaks?" is no.

You can read / write a local or a global as many times as you want without leaking.

There are situations where it's not the most efficient solution, but unless your globals are large-sized, don't worry about it.

If you lose 100 bytes per second for 15 minutes, that's 90k bytes in all - how is that using up all your physical RAM?

I would turn on highlighting (the light bulb) and watch any arrays you store in shift registers, or locals or globals. Run thru the code and watch the labels appear on the arrays - they show how many elements are in the array. If the number keeps climbing, find out why.

You might also consider a separate thread to
look at the globals and display how many elements each contains, say every one second. That might tell you which array is getting overstuffed.

[jim006]

The metric should have been 100k bytes instead of 100 bytes... regardless, I just tracked down the memory leak:

I had a "register for events" VI inside a while-loop that was executing every 100ms. That was burning up some serious RAM.

Is there a "best practices" for freeing up unused memory?

For example, if I load a picture from file into a picture indicator, do I need to free up the memory associated with the previous picture that was displayed?

Similarly, if I write a string to a string indicator, do I need to free up the memory associated with the previous text that was displayed?

Do constants stay around? If I create a string constant in a case structure within a while-loop, when is that memory freed? What about when LabView encounters
the same constant within a while-loop... is new memory allocated each cycle, or is it the same memory as the previous cycle?

[CoastalMaineBird]

Is there a "best practices" for freeing up unused memory? 

--- Generally you don't need to - LabVIEW will figure out whan something is not used and free it for you. It's better to use wires for large amounts of data rather than globals / locals, for this reason.


For example, if I load a picture from file into a picture indicator, do I need to free up the memory associated with the previous picture that was displayed?

--- No. That's done for you.




Similarly, if I write a string to a string indicator, do I need to free up the memory associated with the previous text that was displayed?

--- No. That's done for you.



Do constants stay around?  If I create a string constant in a case structur
e within a while-loop, when is that memory freed? 

--- Well, constants are "created" when you plop them onto the diagram. Their memory is never freed ( until you completely unload the VI containing them).


What about when LabView encounters the same constant within a while-loop... is new memory allocated each cycle, or is it the same memory as the previous cycle?"

--- Same answer. Constants are "created" when you plop them onto the diagram. Their memory is never freed. Each time thru the loop, it uses the same memory.


The biggest hurdle to overcome when moving to LabVIEW from some other language is realizing all the crap you don't have to worry about anymore.

[jim006]

Thanks for all the feedback... it was very helpfull!

Jim

[m3nth]

Somewhat along these lines... is it advantageous at all to pass a reference to a large array to subvi's instead of passing the array itself?

[CoastalMaineBird]

Well, there's no such thing as a reference to an array - at least not in the conventional sense (a pointer to the data).

You could pass a CONTROL reference - a "pointer" to the front-panel control that contains an array. But keep in mind all arrays don't exist in a control.

If you mean a CONTROL reference - It's NOT advantageous. It's probably worse.

If you pass a large array from main to subVI through wires, LabVIEW is smart enough to decide whether it needs to make a copy of the data. It'll make a copy if the subVI modifies the original, and the main does something else with the unmodified array.
If your subVI just reads elements from the array, or otherwise just looks without touching, LabVIEW will not make a copy.

However, I'l
l bet that if you pass a control reference to a subVI, and use the VALUE property to extract the value, then you are making a copy of the data, whether you change it or not. The reason is that you've broken the dataflow paradigm - LabVIEW doesn't know when you read the data (you could stash the reference and read the data a hundred times later on). So it cannot optimize for you.
It doesn't matter much on small data - integers, doubles, small strings, etc. But on arrays of large data, you want to avoid copying unless absolutely necessary. For that reason, avoid locals, globals, and references for large data.

[Greg_McKaskle2]

> Thanks for all the feedback... it was very helpfull!
>

Most of your questions have already been answered, and quite well.
There is one guideline I'll add that wasn't mentioned. When you are
looking at a palette and decide to use a node named Open xxx, and there
is a node in the palette called Close xxx, you are responsible for
closing it. If the program ends and it hasn't been explicitly closed,
LV will try to close it for you, but until the program ends, LV doesn't
know if you are still using it or not. Unfortunately, not all of the
functions that explicitly allocate are called Open and Close, some are
called Create, Connect, or Register. But spend just a second to see of
there is a Release, Destroy, Disconn
ect, or Unregister, and when you are
finished with the resource, call the matching function.

As stated earlier, data LV can deal with, it is refnums and references
that usually require explicit actions, and those are a bit more
complicated to deal with.

One other tool to help track down memory leaks or hoarding, is the
profiler. You need to make sure that your app finishes before the top
level diagram is tallied, but even aborting your app will work, then
look at the results for large pieces of memory. Although I don't think
it would have helped here since the data wasn't being stored.

If you have other questions, fire away.

Greg McKaskle