LabVIEW
find indices of elements in 1d array
Solved!
OK, quick summary for 1M size arrays:
- [In range and coerce] is slightly faster than [Abs, <1].
- The conditional tunnel creates frequent spikes.
- Preallocating the output, then trimming later is better (code #3)
- Building the array as in Chris's code is about 8x slower (not shown, but as expected. Only OK if a match is a rare event)
- For smaller array sizes, the difference are not significant enough to warrant more advanced code.
ChrisK88 wrote: Insert into array should have been my go to with pre-allocation
No. It is Replace Array Subset with pre-allocation. Insert Into Array is just another version of Build Array.
Just thinking outside the box, alway try to find alternative solutions.
Here are two completely different approaches.
They are within a factor of 2 of the fastest so still OK. (WHILE is faster than FOR)
@ChrisK88 wrote:
So obviously the less arrays you carry in any loops is better for memory allocation, but in the case of build array or insert into array like I originally had, you would say that's not efficient because LabVIEW is creating a copy of the array within that loop and if it's huge, then obviously performance takes a hit? I'm trying to understand the compiler, which is something I struggle a bit with.
If you built an array in a loop, the compiler does not know what the final size will be and needs to guess. Initially it will allocate a small amount, but whenever it runs out of space, it needs to reach out to the memory manager and request a larger contiguous chunk of memory. Then it needs to copy the entire existing array into the new and larger location. (Arrays are contiguous in memory!). This process repeats regularly but it preemtively allocates progressively larger extra space, guessing that it will keep growing. (This is quite smart. If it would need to request a new allocation for each added element, it would take forever!).
If we preallocate with a size of the worst case scenario (=all indices retained), there is only a single call to the memory manager and the entire loop code operates "in place" (this is the magic word!). After the loop has finished, we need to trim back to the actually used elements, but that is also cheap.
Once allocated, the array size itself has basically no effect on speed. Even if you would initialize with a 10M element array, the loop itself would take about the same amount of time.
@ChrisK88 wrote:
Also, in my company we can not use OpenG or any non native LabVIEW primatives, crazy source control rules, so I always have to re-invent some stuff, like search array, where in LabVIEW it only outputs the first index, not an array of indices.
I'm sure preaching to the choir doesn't help, but OpenG has some of the most relaxed licensing possible. They basically say you can use the source anyway, including modifying it, and use it in commercial applications. So you can actually just copy the source that OpenG is doing into a new VI and save it as your own keeping the BSD license of course. There is no practical reason to not allow OpenG at a company other than paranoia, or stubbornness against open source software. It's proabably saved me multiple man months (maybe a year) of work to design, develop, test, document, and maintain and I'm just one developer. Of course when it comes to performance OpenG isn't the greatest especially on array manipulation like this, and part of the reason is because you can do optomizations that OpenG can't know of. If all your values you want to find are between 1 and -1 you can do tricks like some already shown to do it more efficiently.
