LabVIEW
Conditional Auto-Index Speed
So I remember seeing a post when the Conditional Auto-Index terminal was made for 2012 saying that the performance was not the greatest, and internally it was just building an array adding an element each time the condition was true. I can't seem to find this information now, but I thought it was said that the performance would be improved in later versions of LabVIEW. This morning I thought I would test it with 2012 SP1.
Attached is a VI that performs a conditional index on an array of random numbers. It does this 4 different ways and then makes sure the results are the same, and then shows how long it took to perform the operation. I found that the fastest method was to preallocate the output, then perform replace operations on the array, then get a subset of the data after. This method will not work for while loops because the number of iterations is not known at runtime. The second place in terms of speed was the OpenG method which would work under while loop conditions. Then in 3rd place is Conditional Index, and close 4th was Build Array the times I got are below for an array of 10M elements.
Preallocate 147ms
OpenG 217ms
Conditional Index 1s 111ms
Build Array 1s 161ms
Is there any plans to improve this performance by performing the index in a more efficient manor?
@Hooovahh wrote:
So I remember seeing a post when the Conditional Auto-Index terminal was made for 2012 saying that the performance was not the greatest, and internally it was just building an array adding an element each time the condition was true. I can't seem to find this information now, but I thought it was said that the performance would be improved in later versions of LabVIEW.
Is there any plans to improve this performance by performing the index in a more efficient manor?
That information was in the LabVIEW 2012 Beta forum. We caught the performance issue in the Beta 2 and was therefore too late to fix for 2012. We were told then that they would try to have it improved in 2013. Maybe you should join the LabVIEW 2013 Beta and see if it is fixed.
As far as I know, LabVIEW 2012 does not have conditional tunnels optimized for performance.
(Your benchmark is not good. You should definitely place all array indicators after the sequence. You don't want an indicator update stealing cpu cycles during benchmarking, You should also disable debugging.)
@altenbach wrote:
(Your benchmark is not good. You should definitely place all array indicators after the sequence. You don't want an indicator update stealing cpu cycles during benchmarking, You should also disable debugging.)
I figured it wouldn't matter as long as I was consistent, if it took an additional 100ms to update the array indicator for the OpenG method it would also take an additional 100ms to update the others. Your comment about debugging is true.
@Hooovahh wrote:
I figured it wouldn't matter as long as I was consistent, if it took an additional 100ms to update the array indicator for the OpenG method it would also take an additional 100ms to update the others.
No, the front panel updates are asynchronous, so an update of a scheduled indicator might occur during testing of a later code segment. It is unpredictable.
I just deleted the array indicators. The only time you need them is when you have a mismatch. And you aren't worried about speed at that point.
Out of curiosity I thought I would revisit this for performance on LabVIEW 2013. I modified the VI to update the array outside of the timing structure, and I also turned off debugging and automatic error handing. Timing is still a random because the values are random but below are my numbers in 2012 and 2013.
2012
Conditional Index: 0.797s
OpenG Index: 0.184
Build Array: 6.109s
Preallocate: 0.101
2013
Conditional: 0.129
OpenG Index: 0.201
Build Array: 0.770
Preallocate: 0.078
So from what I've seen each of the native solutions have improved in speed by some amount, where the OpenG method is about the same. Even with improvements the fastest method is to Preallocate, replace, and get array subset. But at least in 2013 this doesn't save much time over the native Conditional Index.
