LabVIEW
How to avoid memory increase with FOR loops
@Mentos wrote:The problem is that when I run the VIs and watch the Labview memory on the TaskBar it increases by more than 700 MBs (rather then 87MB).
It looks like the memory increase I see on the TaskBar is more or less the multiplication of the Original (5 element) array size by the total number of iterations (10000x5).
Do you have a task manager screenshot from before running the VI? I see a total memory use by LabVIEW of about 700MB, not an "increase by" (size after minus size before). The LabVIEW memory use in the task manager includes everything, not just the data in one output array.
It should be painfully obvious that the calculation would only be valid if the output was exactly the input x 10000 x 5, but it's not. A quick look at the data shows me that it is entirely different. Look at the first cluster out, for example. Each array inside each output cluster has 601 elements in it instead of 2, so of course it's going to be a lot bigger.
Maybe I misinterpreted the problem?
I think I got confused.
@billko wrote:
It should be painfully obvious that the calculation would only be valid if the output was exactly the input x 10000 x 5, but it's not. A quick look at the data shows me that it is entirely different. Look at the first cluster out, for example. Each array inside each output cluster has 601 elements in it instead of 2, so of course it's going to be a lot bigger.
At first I thought the data might be calculated wrongly (flattening to string, etc) but based on 10000*~11 bytes (7 character string, I32)*601 + 4 (I32) I arrived at ~80MB...
When I tried running the VI immediately after starting LabVIEW, I also observed a large increase in the memory being held by LabVIEW, up to around 700, 800 MB (from around 150...). However, when I'm generally going about my programming, I often see LabVIEW using ~800MB - I'd guess this is a typical running value for 32-bit LabVIEW 201{7,9}.
When I repeatedly ran the VI, I observed (using Task Manager) a more reasonable increase of ~80-90 MB. This didn't increase further on subsequent runs.
So I suspect that the initial measurement is wrong (because it accounts for LabVIEW loading some stuff, maybe altenbach knows what...) but that subsequent measurements are pretty much in line with the expected value.
OP: depending on your actual application, you may find you can streamline this a bit by changing your data structures. Replace Array Subset may be less than totally fantastic when you are placing new arrays into the array's element each iteration (since the initializing element is in fact with two empty arrays).
"right after opening" is probably not a good baseline. Also your output array (assuming that the inner data, arrays etc. Does not change size) requires at least 3x the memory you are estimating (wire data, transfer buffer, indicator, etc.). If the code hints that the inner arrays change size, the compiler might also preemptively allocate slack space for each.
Why exactly do you need these gigantic outputs? What does the rest of your program do with it?
So the little bit at the end was just a suggestion that despite the use of RAS, you might not get (won't get? I think arrays could be allocated as pointers in clusters, but I really don't know...) in-placeness because you need more memory than you allocate with Initialize Array.
The 700MB in my case is I suspect not proportional to the cost of the VI, but rather a flat cost to using the LabVIEW development IDE. Assuming that you have enough memory, try changing your 10000 value to perhaps 20000 - this should increase your cost by a factor of 2(ish). If you get to 1.5GB, you'll know something's weird. If you get 700MB + 2*90MB, you'll know there's just a sizeable offset to running LabVIEW.
