LabVIEW
buffer allocation and minimizing memory allocation
Solved!
QFang wrote:
-My reasoning (though it was flawed) was to tell the compiler that "I do not need an extra copy of these arrays, I'm just going to take out some of the values".. Since a fork in a wire is a pretty easy way to increase the chance of data duplicates, I figured that the IPE index function, by nature of removing the need to split, or fork, the array wire (it has an in and an out), I would avoid duplication or have a better chance of avoiding duplication.
It's important to realize that buffer allocations only occur at nodes, not on wires. While it may seem like forking a wire makes a copy of the data, that's not the case. At most the fork will cause a reference counter to increment. LabVIEW memory allocation is copy-on-write - no copy is made until data is actually modified, and even then, the copy is made only if there's a need to maintain the original. If you fork an array to several index array functions, there's still only one copy of the array. Also, the LabVIEW compiler tries to schedule operations to avoid copies, so if several branches read from a wire but only one modifies it, the compiler will try to schedule the modifying operation to run after all the reads are complete.
QFang wrote:
After having looked at several more cases (as I'm writing this post), I can't find any array operation that I'm doing in my code that reduces the black dots by including an IPE.. As such, I must STILL not understand IPE's correctly, because my conclusion at the moment is that you "never" haver to use them. Replace a subset in an array? no need to use them (in my code). Indexing out elements? no problem. .
An IPE is useful for replacing an array subset when you're operating on a subset of the original array. You pull out the elements you want, do some calculations, and then put them back into the same place in the array. If the new array subset comes from somewhere other than the original array, then the IPE doesn't help. If the input and output sides of the IPE don't connect to each other, then there's no benefit to the IPE.
I'm attaching an image of some code I wrote recently that makes use of IPEs, with buffer allocations shown. You can see that there's only one set of buffer allocations, after the Split 1D Array. I could have worked around that but the way I wrote it seemed easier, and the arrays are small and it's not time-critical code so it doesn't need any optimization. Also those arrays are always the same size, so it should be able to reuse the same allocation on every iteration of the VI rather than allocating new arrays.
Another important point: buffers can be reused. You might see an allocation dot on a shift register, but that shift register only needs to be allocated once, on the first call to the VI. Every following call to the VI reuses that same location. Sometimes you don't see a buffer allocation even though one effectively occurs. Resizing an array could requiring copying the entire array to a new larger location, and even though LabVIEW needs to allocate more memory for it, you won't always see a buffer allocation dot. I think this is because it's technically reallocating an existing array instead of allocating a new one, but this has always puzzled me a bit. On the topic of arrays, there are also times where you see a buffer allocation dot but all that's being allocated is a "sub-array" - a pointer to a specific part of an existing array, not an entirely new copy of the data. For example Reverse 1D Array can create a sub-array that points to the end of the original array with a "stride" of -1, meaning it advances through the array backwards. Same thing with array subset. You can see these sub-arrays by turning on context help and putting the cursor over a wire that carries one, as shown in this image.
There's unfortunately not much you can do about string allocations. Fortunately, I've never seen that be a problem, and I've had systems run continuously for months that used strings on limited hardware (the Compact FieldPoint controllers) for both logging to disk and TCP communication. I would recommend moving the string operations out of time-critical areas and into separate loop. For example, I put my TCP communication in a separate loop that also parses the incoming strings into specific data, which is then passed by queue (or RT-FIFO) to the time-critical loops so that those loops only deal with fixed-size data. Same idea with the logging - do all the string conversions and path handling in a separate loop.
