Why do these two Reshape Array operations result in a "Memory is full" error in LV86?

[altenbach]

Another thing:

I am questioning the presence of the "request deallocation" primitive, because it will not do anything to data in USRs (and it better not!). As you can easily see if you run the VI a second time with execution highlighting, the full size arrays are still contained in the shift register.

Can you elaborate why you have it there?

[GuenterMueller]

In LabVIEW 8.5 and earlier, I observed that the memory usage of the VI much was higher than expected (Maybe a buffer used by a Reshape Array function was still allocated?).

Requesting a Deallocation solved this issue and made the memory usage very close to the amount of data in the SR.

[GuenterMueller]

Curios: Back in my office this morning and working now with my office PC I see, that all the workarounds given in this thread still result in a "Memory is full" error. (When posting yesterday I was using my notebook.)

Must be something PC specific. Just to make sure that it isn't just an issue with the amount of RAM I went from 1536KB to 2048KB this morning.  The "Memory is full" error is still there.

Should I be concerned about my AMD X2 CPU?

[Jarrod_S.]

The amount of physical memory in the computer shouldn't really affect the Out of Memory messages. Windows will allow LabVIEW to allocate up to 2GB of memory regardless. If that memory doesn't actually exist in the system, Windows will page some other things in memory (or part of LabVIEW's) to disk. This will drastically decrease performance, but I'm only pointing it out so that you know the memory error message shouldn't be machine-specific.

That being said, there are other factors which can influence memory availability. One is memory fragmentation. As LabVIEW (or most any other program) acquires and releases memory, the contiguous memory spaces available become smaller and smaller. You end up with a memory space that looks like swiss cheese. So you might technically have 1.5 GB still available, but no one spot bigger than, say, 200MB. So if you tried to allocate a 201MB array, you'd get an out-of-memory message. The common lesson here is that it's usually safer to allocate multiple smaller arrays, than one big one.

Obviously the code you're using used to work "as is", so it kind of sounds like a cop-out to suggest retooling it now, but I just wanted to throw out options.

Another option you could try quickly would be to increase the amount of memory LabVIEW can address. The default is 2GB total, but there is a Windows OS switch you can throw to allow LabVIEW to allocate up to 3GB. This might help, too. This is only available with LabVIEW 8.5 and on. Earlier versions weren't large-address aware. Check out this thread to see if it helps. It's a quick thing to try that doesn't involve changing code, but it might only obscure a deeper issue.

[GuenterMueller]

My guess is that this is a memory defragmentation problem, too, Jarrod.
For that reason I repeated my test just after the operating system has started. This doesn't change the situation.
Then - in a second stage - I bumped the amount of RAM to 2048MB. If there is only enough space to allocate one of two big arrays after reboot it seemed reasonable to add further RAM and check if then both arrays can be allocated. (Or in other words: Why should Windows XP startup and continue teasing me by again fragmenting the (now increased amount of) memory that much that I cannot allocate two arrays of this size?)
BTW: I posted your VI and Christian's approach to a colleague. He executed both VIs on his notebook. They work fine - as they did on my notebook yesterday. I am more and more getting convinced that it is specific to my PC. Bad luck.

Guenter