<https://lavag.org/topic/6534-memory-fragmentation/#comment-38239>
<http://schema.org/text>
"QUOTE(jlokanis @ Nov 13 2007, 02:11 PM)  \n\nWell, if you need to add data, you need to add data. That memory has to come from somewhere. There is a distinction, however in resizing an existing buffer versus allocating a completely new one. You can't allocate a new buffer with the inplace element structure, but you can resize that buffer. LabVIEW's in charge of resizing buffers for you so you don't have to think about it. I'm pretty sure (although this is hearsay) that what it does is resize the buffer to be bigger than you requested so that there's room to grow. Then when you grow beyond those bounds, it resizes again. That way it avoids constant allocation. \nBut if you don't trust that or want to customize it, you could implement the same functionality. Just initialize a very large array of elements and have a field in your cluster that denotes where you are in that array and its size. Then use Replace Array Subset instead of Build Array until you run out of room. Then use Reshape Array to resize the array to be twice as big, for instance. That's a sustainable model that requires relatively little memory allocation and should run smoothly. \nRegarding the Variant Database Norm's speaking of: Yes, I believe LabVIEW will be forced to make copies of items when you check them out. An overkill method might be to store many single-element queue refs in the Variant Database instead of the data directly. Then you're copying a queue refnum (32 bits) instead of the whole thing. That's kind of a pain, I admit. \n"
<https://lavag.org/topic/6534-memory-fragmentation/?tab=comments#comment-38245>