LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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?

0 Kudos
Message 1 of 7
(3,516 Views)

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


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 7
(3,509 Views)

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

0 Kudos
Message 3 of 7
(3,503 Views)

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

0 Kudos
Message 4 of 7
(3,480 Views)

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

0 Kudos
Message 5 of 7
(3,472 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 7
(3,469 Views)

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.

Message 7 of 7
(3,389 Views)