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

[altenbach]

Since a few LabVIEW versions ago, the LabVIEW FFT implementation is top notch in speed and very comparable to e.g. fftw (http://www.fftw.org/). for any array sizes. I recommend to stick with it. Don't complicate your life with C. 😉

[Jarrod_S.]

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. 😉

[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:

http://forums.ni.com/ni/board/message?board.id=170&message.id=6685#M6685

🙂

[tlivingston]

I think we're all on the same page..  While loops and indexing are not totally in efficient. But This application he's pinching pennies..

I did not mean to suggest that there might be a better FFT function in C. The entire application however seems to be very high speed and processor intensive- Something a lower level language is usually better suited for. There is a reason Device Drivers are not written in labview...
Im sure Labviews FFT function is written in C under the covers....

[aarthisiva]

So can you please suggest some actions which would make this application work more efficiently in terms of speed?

Thanks,
Aarthi

[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.

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.

Now we have a VI containing real data and I can try some bechmarking and profiling. 😄

I also suspect that it would help to place most of the code (trimming, scaling, etc.) within thread 3 inside the FOR loop.

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.

[tlivingston]

There is nothing in your application that jumps out as a place for improvement- its just doing a lot of work.

You may want to analyze your algorithm a bit to see if more functions can be performed in a single pass, or maybe the mathematics can be simplified? Maybe working with matrices rather than arrays could gain efficiency?

[aarthisiva]

Sorry for getting back late.. I need three independent loops because I am trying to implement multithreading here.. One is a data acquisition thread, the other is a processing thread and the last one is the display thread.. Actually the last thread is also doing some processing.. Since one part of processing is done via rows and the other via columns I have split them in to two threads to make the whole process quicker.. In that way the first processing will not wait when the second one is going on.. It will justgrab the next acquired data and start processing on it and send the result to the next thread..

I have removed the IMAQ stuff and attached the code. Kindly let me know if you can think of some way to increase the speed. I will clean up the program as you said.

Thanks,
Aarthi

[altenbach]

OK, 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 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.

[Bhavnesh.Patel]

altenbach you are putting it all in one loop reduced the execution time to 35ms from 50ms on my machine