Array Preallocation and Memory Management

[nathand]

Hold on, no need to make changes to that VI, there's no problem with it. It is OK to use build array in a loop the way you're doing it. You should not use build array in a loop where one input to build array is also the build array output, through a shift register, because that creates an array that grows on each loop iteration and forces a lot of memory reallocation. However, in your code, you are building a small array of the same size each loop cycle. That means that array can be allocated once and reused. In addition your use of Replace Array Subset is exactly the right thing to do.

Your program might have other memory problems, but they're not in the VI you're showing us.

[S1ack]

Well that's a relief. Thank you for the insight.

So...the VI Analyser Tool Kit is not smart enough to know this? (Actually it didn't flag this particular instance as it resides in a timed loop.)

Still need to analyze the profiler data after it runs some more but I was getting ready to add a for loop, an initialized boolean array, etc.....And was not looking forward to that massive effort.

Tested this

[altenbach]

---

S1ack wrote:

Tested this

---

Can you explain the purpose of the attached snippet? It is not clear how it fits in the rest of the discussion and you don't tell us what the outcome of your "test" was. 🙂

In this case, you could eliminate all shift registers and just autoindex the scalar from each iteration at the right loop boundaries. You'll get exactly the same memory footprint and have singificantly less code. Since you wire a constant to N, the output array can be fully allocated by the compiler at compile time and re-used with every call.

What is the purpose of the wait in the innermost loop? How big is the chance that one of the controls changes during the execution if the inner loops? Most likely, all controls are constant during any single iteration of the while loop, and it is thus most efficient to place all controls outside of all FOR loops.

In any case (except for the wait in the innermost loop), the following will give you exactly the same result with no memory penalty. None of the loops are necessary.

(In your original code it is not clear if this solution can be applied, because you don't give any indication on the size of the input array, for example. (If the size is 30, it should be applicable). You might want to keep the case structure just because of the large number of variables, but simply autoindex at the right loop boundary if all elements are replaced anyway.

[S1ack]

---

@altenbach wrote:

Can you explain the purpose of the attached snippet? It is not clear how it fits in the rest of the discussion and you don't tell us what the outcome of your "test" was. 🙂

In this case, you could eliminate all shift registers and just autoindex the scalar from each iteration at the right loop boundaries. You'll get exactly the same memory footprint and have singificantly less code. Since you wire a constant to N, the output array can be fully allocated by the compiler at compile time and re-used with every call.

What is the purpose of the wait in the innermost loop? How big is the chance that one of the controls changes during the execution if the inner loops? Most likely, all controls are constant during any single iteration of the while loop, and it is thus most efficient to place all controls outside of all FOR loops.

In any case (except for the wait in the innermost loop), the following will give you exactly the same result with no memory penalty. None of the loops are necessary.

(In your original code it is not clear if this solution can be applied, because you don't give any indication on the size of the input array, for example. (If the size is 30, it should be applicable). You might want to keep the case structure just because of the large number of variables, but simply autoindex at the right loop boundary if all elements are replaced anyway.

---

Sorry, did not mean to confuse. Probably should not have posted that. Outcome of the 'test' was that I managed to get the data in the place I wanted without use of the build array function. The test was just to start from a blank VI and add another for loop for the Booleans.

The wait in the inner most loop was to slow things down so as to view the indexing - I am a newcomer to Labview.

The original code is from my project and the u16 array is 120 elements (maximum for Modbus) the first 30 of which are Booleans. In any case, the whole point has been rendered moot by your and nathand's statements that there is no memory penalty despite what the VI Analyzer Tool Kit results told this noob. For that I am grateful.

[nathand]

---

@S1ack wrote:

The original code is from my project and the u16 array is 120 elements (maximum for Modbus) the first 30 of which are Booleans. In any case, the whole point has been rendered moot by your and nathand's statements that there is no memory penalty despite what the VI Analyzer Tool Kit results told this noob. For that I am grateful.

---

I'm still a bit confused. You said that the VI Analyzer didn't flag this instance, so as far as we can tell the tool did not mislead you. It might be helpful for you to post an instance where the VI Analyzer does report a problem, and show both your code and the problem as VI Analyzer describes it. If the VI Analyzer right then we can help you fix a real problem with your code, and if it is wrong, posting your code may help improve it (NI employees read these posts).

[S1ack]

The tool report states that this particular error is not looked for within timed loops. I do not understand the rationale, if it is bad in a while loop, why is it not bad in a timed loop? I re-worked the errors that it did find, then it occured to me later that I had many more build arrays in timed loops - which is what prompted this thread revival. I will likely go back and undo my changes to the while loops I did 'fix' because they do not wire output back to input via shift register either.

[nathand]

---

@S1ack wrote:

I do not understand the rationale, if it is bad in a while loop, why is it not bad in a timed loop?

---

This is probably a limitation of the analysis tool, and not a difference in performance between a standard loop and a timed loop.