Memory Management Problem

[Jim77215]

I have a VI that typically runs for hours, accumulating test data which is displayed within a string indicator. As the hours go by the VI's memory consumption creeps up until finally, because of sluggish execution, LabVIEW must be exited and restarted.

I think my problem is with the way the test data is accumulated. I've written a small test case VI to simulate the issue and have attached 3 pictures, called Memory1, Memory2 and Memory3 for illustration.

In the picture Memory1.jpg, LabVIEW has just been started but nothing yet has been executed. Note the Memory reading as a starting reference point. In Memory2.jpg, the VI had been executing for several minutes before it was stopped. As expected the memory consumption has increased. In Memory3.jpg, the Purge button is clicked and the VI is run, clearing out the string indicator and the shift register. Note that the memory consumption does go down, BUT....not all the way back to the starting memory consumption. As I repeat this process over and over, the starting point for memory consumption is always higher than the previous run. As the hours go by I end up with sluggish VI execution that cannot be fixed until I exit and restart LabVIEW.

Is there anyway to prevent this problem without exiting LabVIEW?

Thanks!

[TroyK · Accepted solution]

When you click the 'purge' button, it will clear the indicator and shift register but may not necessarily de-allocate memory.

I believe it should reuse the pre-allocated memory though.

If you want to make sure LabVIEW flushes the pre-allocated memory when you hit the purge button, you'll need to put your data collector loop in a subvi and add a 'Request De-allocation' Function to execute inside the subvi when you press the purge button.

Palette: Application control > Memory control

I'm not too sure about the way you're building the string in the unintialized shift register. It's a classic recipe for a memory leak.

LabVIEW takes a guess at how much memory you need, and then has to keep re-allocating as the size of the string increases. Constantly building a string/array can be a time consuming process and results in fragmented memory.

You should also use the Request De-allocation function sparingly, it forces LabVIEW to reallocate memory and can cause a performance hit by constantly having to re-allocate the memory it's using.

[altenbach]

Of course your code does not make much sense. What is the purpose of the inner loop?

(You should either place the SR in the outer loop or use a globally initialized feedback node instead).

How much data goes into the indicator in the real-world case? (a "infinite speed" loop is probably not realistic).

[Jim77215]

The code in the pictures was just an example I put together to illustrate how the memory was spiraling upwards

[RTSLVU]

Having had to deal with a similar issue in the past with a program the collected data from a serial port.

I found it best to save the data directly to a file every time data is collected and only display a certain amount of recent data on the screen.

I decided to limit the string size of the on screen indicator to 10,000 characters and simply replace the contents of the indicator with an empty string when it's leangth is grater than 10,000.

If someone needs to see further back than (in my case) about an hour they can just open the data file.

I was always going to put a function in my program to load the file for viewing but nobody ever really complained about having to open the file. In fact they almost prefered it as they could just copy the file and go back to their desk to look at it.

[Vasilich2004]

I had similar issue with array. Try to connect empty string to "Shift register" (above "Hello ..."). That should help.

In any case I suppose that is bug.