LabVIEW
Is Delete From Array function optimized while deleting from the front or end of an array.
Solved!
@hlcfreelook wrote:
I seldom caught up with such large data so frequently I have used Delete From Array function in my program to access portions of arrays, especially accessing the last elements of arrays which is very convenient by Delete From Array.
Please define what you mean by "access". To get a single element, you would use index array and to get a subset of the array, you would use "array subset". Both don't resize or touch the original array, which is the ideal case. The "delete from array" function typically creates two new arrays, the deleted portion and the original with a part deleted. There are many scenarios where the operation must copy both arrays.
Can you describe in more detail how you are accessing the array and what you do with it later?
Sorry for the vagueness.
When I am using Delete From Array, sometimes i just want to see the elements of the last row, other times i want to split the array into two parts (the first row and the others) for later calculation (shown in attached png).
Surely I can do both tasks with Array Subset. But I have unconsciously use Delete From Array in my previously codes as it is more handy for these tasks than Array Subset. While using Delete From Array, in the first task you don't need to know the array size beforehand and in the second task you get both potion of the array through one function.
So I asked myself, "What would Crossrulz do?". I'm not sure this would be the answer, but anyway ...
I did an experiment. I generated a 1000x1000 array of random numbers, then did the following: Timed how long it took to do 1000 removals of the last row, 1000 removals of the first row, and 1000 removals of row 123 (a "random" row).
The answer was it took 3.76 ms to remove the first row, 3.57 the last row, and 3.26 a middle row. Yea, but how reproducible was this? So I wrapped the entire thing in another For loop and did that 1000 times. The results were shocking!
The first set of Times were roughly twice as long as all the rest! I split out the first times, took the mean and standard deviations of the rest, and the results are shown below. Note that now we get a more "expected" order, first and last row deletions are slightly faster than middle, but again, the difference is small enough that for arrays of this size, the question is moot.
It might be interesting (for the Experimenters out there) to vary other things such as Array Size. But it might also be fruitful to say that the folks at NI who implement the LabVIEW code have a lot of experience in optimizing the code, so we should probably not worry to much about it.
Bob Schor
Lets see how much we can learn from this benchmark. If you disable debugging, it completes in an instant because of dead code elimination. From the similarlty between the various delete locations (when debugging is enabled and dead code executes), we can conclude that there is probably no signiificant in-place optimization when deleting from one of the ends. Then you also left out the interesting case where you delete columns instead of rows. Also this case takes a similar amount of time and since arrays must be contiguous in memory, I suspect that ALL variations create a new copy for the outputs, otherwise we would see large differences. Just guessing.
Any time "delete from array" is used repeatedly in a relatively tight loop, there is probably a better way. Often the entire algorithm can be desinged to be much more "in place". If I use this function, I use it exactly once before any tight loop.
