Auto-Indexing For loops by columns of 2-D array

[altenbach]

In contrary to what otheres have said, autoindexing is very efficient, because the LabVIEW knows the final array size from the beginning, it is nowhere near as inefficient as building an array inside a loop. Maybe you should arrange your data so the first loop would do the rows instead?
 
Autoindexing by colum would be much less than autoindexing by row, because to get a colum, LabVIEW needs to extract nonadjacent elements, while autoindexing by row just gets a contiguous subset of the data in memory.
 
Still, you should probably feed your 2D array via a shift register in each loop, then index out out and replace colums or rows as you go.
 
Can you attach a simple example of your code?

[altenbach]

Jarrod S. wrote:LabVIEW does make auto-indexing in a While Loop as efficient as possible by allocating memory in large chunks and then discarding unused portions after the loop finishes running. This helps LabVIEW go through the process of memory allocation as infrequently as possible. It's a good compromise, and worth noting. ;)


At the risk of quoting stale information, here's how LabVIEW did this in 1999:
<a href="http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=6685#M6685" target="_blank">http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=6685#M6685</a>
:)

[altenbach]

It is difficult to tell by looking at the code you posted, because it seems that there is much more to the program than you show. Why do you possibly need three independent loops linked by queues? That is a lot of data shuffling with many extra data copies.
&nbsp;
Can you create an indicator on the wire coming out of the "IMAQ Image to array" node, run the VI once with real data, then right-click on the new indicator terminal and select "change to constant". Now delete all IMAQ stuff and post it again.
&nbsp;
Now we have a VI containing real data and I can try some bechmarking and profiling. :D
&nbsp;
I also suspect that it would help to place most of the code (trimming, scaling, etc.) within&nbsp;thread 3 inside the FOR loop.
&nbsp;
In the meantime, you should also clean up the program a bit to get rid of all these coercion dots. You have array index constants as DBL, multiply DBL arrays with I32 constants, etc. Then you have all these hidden wires and righ-to left wires that make the diagram hard to read. Rule of thumb: If you cannot follow a wire by looking at the diagram (no clicking allowed!), its not good. ;) It won't gain you much speed, but it makes debugging much easier.

[altenbach]

OK,&nbsp;I took a quick stab at it and got it about 5.3x faster than your version. (280ms vs 1.5 seconds on my slow laptop)
I still don't uderstand the reasoning of multiple loops. LabVIEW is always multithreaded and since your queues are size=1, things need to execute in order anyway. You are just creating extra data copies of large arrays. Are you running on some fancy multi-CPU hardware? (Even then it might not make a difference. LabVIEW usually does a great job arranging the code execution. Trying to micromanage this&nbsp;has no benefit)
There are some extra comments on the diagram (LabVIEW 8.0). Modfy as needed. I currently left it at two loops, but you could even combine all into one.


For-LoopSamp280ms.vi:
http://forums.ni.com/attachments/ni/170/182804/1/For-LoopSamp280ms.vi