Memory management for complex structures

[Bublina]

Hello,

I was able to identify my problem, I have attached a small example to show it. The VIs are made in LV2010 sp1.

Run the compare.vi. It loads some binary files from directory "tiny", saves them into directory "huge", loads both again and compares.

Yet, I don't know what to do about it. I have tried several ways to load the data, using different techniques, but the result is always the same.

[GerdW · Accepted solution]

Hi Bublina,

"Run the compare.vi."

I don't have IMAQ installed here. But when I remove all those (missing) typedefinitions I can run your conversion routine (1st frame of "compare" sequence). And guess what: without IMAQ it doesn't blow up the tiny files into huge ones...

"I dont think that IMAQ picture data handling is related to this problem."

IMHO it's completely related to IMAQ data handling. See my test result above!

"if you load a file from HDD into RAM, it will consume similar amount of memory in both."

That doesn't need to be true for picture files. They often are compressed, resulting in much more memory consumption when loading them into RAM...

[Bublina]

Hi GerdW,

You are very right, I tried to disable the part of code, where I allocate the memory for pictures and load these pictures in it. As a result, the main application did really load small binary files,

and stored them small. I was the whole time convinced, that the reference only carries the information about the location of the picture in memory.

The example I posted resulted in saving big binary files, becouse I was simultaneously working on the main app, and all the pictures were loaded into memory.

I will probably have to rework the code, so it saves the settings after the memory with pictures is deallocated. I hope I am correct, I will post the results of it.

So far the application was storing these binary files anytime, user made some changes, and the memory with pictures was dealocated, when the program stopped.

[DFGray]

Your load2.vi fragments RAM more than load.vi.  This is because in load2, you are resizing an array at every iteration.  Arrays must be contiguous in memory, so a new, larger memory space may or may not be necessary to extend the array.  The old space is deallocated, but this leads to memory fragmentation, which can cause as many problems as not having the memory.

Take a look at the tutorial Managing Large Data Sets in LabVIEW (or look in your LabVIEW help on the same subject).  You may also want to take a look at this post on memory allocation in loops.

[Bublina]

Hi DFGray,

load2.vi was just a desperate effort to make things work, i know this is the wrong way.

[Bublina]

Thanks for help to everyone,

kudos for GerdW. I reworked the application to save settings to disk after the memory is freed, and it works just fine.

[altenbach]

You typically should mark the most helpful post as solution, not your own "thank you" post.