03-09-2006 10:18 AM
03-09-2006 10:30 AM
My understanding of LabVIEW's internals would lead me to believe that both approaches take about the same amount of time. I'd be interested in the results, though, if somebody ends up benchmarking it.
-D
03-09-2006 11:03 AM - edited 03-09-2006 11:03 AM

Message Edited by GerdW on 03-09-2006 06:04 PM
03-09-2006 11:13 AM
03-09-2006 11:28 AM
03-09-2006 11:54 AM
03-09-2006 11:58 AM
03-09-2006 12:17 PM
Here's a little benchmark. It test for and while loops, both with indexing and built array.
It gives really interesting results! It seems that Labview has a very smart optimizer built-in.
For iterations below 100 000 there isn't really much difference. All are very fast. The indexing loops are about twice as fast as the built array loops.
But above 100 000, strange things start to happen. The first time that you then run the benchmark, there's suddenly big differences. The indexed for loop stays equally fast. The indexed while loop suddenly becomes 10 times slower than the indexed for loop. When you run it a second time, than the indexed while loop is just as fast again as the for loop.
Seems to me that when using indexing, Labview creates a array of 100 000 elements before the loop, and then fills it. That's why it suddenly gets slower when you ask for a longer while loop. (It couldn't predict the size beforehand, like it can with the for loop. Apparantly... either the array stays in memory, or the optimizer remembers the previous number of iterations, because it runs much faster the second time.
The built array seems to be able to do something similar... But it stops at 250 000, when it start to get really slow in comparison to the indexing. At those numbers, running the program multiple times does not increase the speed for the built array loops.
Conclusion: for "small" numbers, Labview seems to be optimized far enough that it doesn't really matter.
For big numbers, indexing is much better than built-array. An indexing for loop is better than indexing while loop, but Labview can optimize very well when the number of iterations stays the same for multiple calls to the vi.