is array building in a loop ALWAYS bad?

[Garvacious]

We've all heard that building arrays in a loop is a bad thing, but what if you are not resizing the array?  Is LV smart enough to know not to build a new array or reshuffle memory every iteration of the loop?

See the example below-the false case (not shown) is just the shift register wire carried over from left to right.  Each time the True case runs, a Build Array is used, but the array is not resized- it is always 3 elements.  So-  is there really any advantage to NOT using the Build Array here?  I assume LabVIEW knows not to keep allocating new memory, becuase the array size has not changed and the previous array is being discarded. 

[CoastalMaineBird]

I assume LabVIEW knows not to keep allocating new memory, becuase the array size has not changed and the previous array is being discarded. 

That really doesn't matter here.

Array-building inside a loop is not inherently "bad", it's just not the best solution in a majority of cases, specifically ones where you build the array every time thru.

If you append a new element EVERY time thru, then just us autoindexing and be done with it - it's more efficient for the processor, and for you.

Whether LabVIEW allocates new memory or not is truly immaterial for a 3-element array done in response to a user click.  If you want to FORCE the issue, use REPLACE ARRAY ELEMENTS to replace the elements with new random numbers (don't forget to initialize the array outside).

In your case above, do it the way you did it and ignore the nipping at your heels. 

Message Edited by CoastalMaineBird on 10-16-2009 05:13 PM

[smercurio_fc]

As noted, building an array in a loop isn't always bad (though that depends on your definition of "bad"), but you must be aware of what happens so you can control it, and not let it cause memory issues. There are two fundamental problems with using Build Array in a loop (note that I am speaking in general terms here, not about your specific case): continuous "memory thrashing" as LabVIEW has to request allocation of more and more memory, and memory fragmentation. Each of these actually affects the other. As memory gets deallocated and allocated, memory fragmentation occurs. As memory fragmentation increases, the extent of the memory thrashing can increase. Eventually you have so much fragmentation that you will not be able to allocate a large enough block for your array. Remember that arrays must be contiguous in memory.

With all of that said, what happens in your example? Well, this situation is a little different for two reasons. First, with while loops you actually have a different operation of Build Array. When Build Array is used in a while loop to create, for example, an auto-indexed array at its output, LabVIEW does not allocate memory at each iteration. Memory will get allocated in large chunks. Once the loop completes, the array gets resized based on the final number of iterations. Second, you are using a shift register to carry the array around. This means buffers can be reused. As mentioned, building an array of just three elements isn't very interesting. What would be more interesting is if you were to build an array of, say, 1,000,000 elements using Initialize Array. If you did this with your example and ran the code with Reset off you would see a jump in memory usage when you set Reset to True. What would happen if the switch is left to True? What you would see is that the memory usage for LabVIEW would not continuously increase. It would actually stay the same. The CPU, on the other hand, might start having a fit. The memory footprint doesn't change since the buffer can be reused. However, the buffer has to be filled in with new values, which is where the CPU starts to give your fans a workout. 

Note that I am ignoring the fact that your loop is a greedy loop. Putting in a small delay would prevent the 100% CPU hit, but in the case where you're creating an array of 1,000,000 elements you'd still see a fairly large CPU usage level.

[Garvacious]

Thanks for the feedback- I should have mentioned that my example was generic and simple to help demonstate my question.  I was not asking specifically about that particular code, just trying to get some feedback on using Build Array continuously to build an array that is not resized.    I have some other code where the array is bigger and more complex- but the idea is the same.  I am trying to avoid unnecessarily complicating the code- Build Array is just clean and easy compared to initializing and replacing elements, just maybe not as efficient.

[altenbach]

---

Garvacious wrote:

We've all heard that building arrays in a loop is a bad thing, but what if you are not resizing the array? 

---

I have never heard that!

Only growing or shrinking an array in a loop might not be very efficient, especially if it can grow without limits. In general, any continuous resizing operations on arrays contained in shift registers or feedback nodes is typically bad.

Since you don't show the false case, there is no way to tell what else is going on, so your picture is inconclusive. 😉

You might want to look at the buffer allication display.

[CoastalMaineBird]

Since you don't show the false case, there is no way to tell what else is going on,

Read the description again - it's perfectly clear. 

[altenbach]

---

CoastalMaineBird wrote:

Since you don't show the false case, there is no way to tell what else is going on,

Read the description again - it's perfectly clear. 

---

LabVIEW programmers don't read text. 😄

[altenbach]

---

Garvacious wrote:

Each time the True case runs, a Build Array is used, but the array is not resized- it is always 3 elements. 

---

No, when you first run the VI, the array is size zero, and remains that way until your boolean turns true for the first time. At this point the array is resized to 3 elements and will stay that way. I would recommend to initialize the shift register with an array of three elements, so the size remains 100% constant.

Of course for a size=3 array nobody really cares, but if you are dealing with large data structures, you might keep it in mind. 😉

[smercurio_fc]

---

Garvacious wrote:

Thanks for the feedback- I should have mentioned that my example was generic and simple to help demonstate my question.  I was not asking specifically about that particular code,

---

I took it that way as well.

I realized when I woke up this morning that I had made a mistake in part of what I had said. That's what you get for responding to an email when you're an hour and half past your normal bedtime and are bleary-eyed. When I was referring to the autoindexing with while loops I mixed in the Build Array in there. This was not correct. I was thinking about two things at once (a habit) and didn't realize at the time that I wrote the response that it came out in stuff I wrote. The autoindexing operation with while loops works as I mentioned if you are doing something like this:

 

Sorry for the confusion. Next time I'll make sure to go to sleep before I try to respond to something that requires actual thought. 

Message Edited by smercurio_fc on 10-17-2009 09:16 AM

[Garvacious]

Here's another example to illustrate my question.  Again, it's theoretical.  Obviously in the real world using constants here would be silly, I would normally have ever-changing sources of data and maybe larger arrays involved, there would be loop timing functions inserted, etc.  The generic question I am really looking for an answer to is- does LabVIEW treat the top and bottom loop any differently from each other?  Is the compiler smart enough to understand that the same memory can be re-used every iteration in the top loop?  In other words, is there a need to overcomplicate things by coding something like the bottom loop?

I do this kind of array building in a loop occasionally when tyring to plot multiple plots on an XY Graph.