Loop Indexing

[mje]

Consider this fairly typical scenario:

• You need to create an array of data.
  
• You know an upper bounds of how large that array can get.
  
• It's computationally expensive to determine the exact size you'll need before hand.
  

Usually getting this done is just a matter of initializing an array to the boundary size, filling it in a loop, then truncating the array when I'm done my calculations and know the exact size.

However, that's a fair amount of code, things can get a little messy when real calculations are being performed. I'm wondering if we use a conditional for loop, does the compiler produce pretty much the same operations?

That is since the for loop is bounded by a Max Size, will the compiler initially allocate an array of that size, then truncate at the end? Or will the operation be analogous to indexing an output on a while loop where the array keeps growing as it needs resizing?

Oops, I forgot to add bounds checking to the while loop snippet...you get the idea. Just imagine the conditional terminal had an additional AND operation in there to check the index, and the resize operation took into account whether the last iteration was successful or not.

[GregR]

LabVIEW will preallocate the array at the max size and truncate as you suspected.

[mje]

Nice!

[JamesMc86]

I asked a similar question about the new conditional indexing in 2012 and that is the same, it will preallocate and then cut down the array which saves writing that code over and over!

[Mads]

According to the LabVIEW 2012 Features and Changes it does not preallocate:

Note The Conditional tunnel option performs memory allocations as often as the Build Array implementation. Therefore, just like with the Build Array function, National Instruments recommends you consider alternatives to the conditional tunnel in portions of your application where performance is critical.

And a quick test I ran just now indicates the same; its performance matches that of a continuous build function. I think a change in this behaviour is planned for LV2013.

[drjdpowell]

According to the LabVIEW 2012 Features and Changes it does not preallocate:

Note The Conditional tunnel option performs memory allocations as often as the Build Array implementation. Therefore, just like with the Build Array function, National Instruments recommends you consider alternatives to the conditional tunnel in portions of your application where performance is critical.

And a quick test I ran just now indicates the same; its performance matches that of a continuous build function. I think a change in this behaviour is planned for LV2013.

There was a big discussion about this on the 2012 Beta forum at NI.com, with a very strong recommendation from most beta testers that conditional indexing behave like regular indexing. I guess it was too late to make the change for 2012.

[Mr Mike]

There was a big discussion about this on the 2012 Beta forum at NI.com, with a very strong recommendation from most beta testers that conditional indexing behave like regular indexing. I guess it was too late to make the change for 2012.

Yes, it was too late. The developer had the new implementation working, but no one was comfortable releasing something that had so little (internal or external) customer testing. Generally we're done with new code months before beta. There were talks about putting it in 2013, but I didn't follow closely enough to know what to expect.

[Mads]

Yes, it was too late. The developer had the new implementation working, but no one was comfortable releasing something that had so little (internal or external) customer testing. Generally we're done with new code months before beta. There were talks about putting it in 2013, but I didn't follow closely enough to know what to expect.

I really hope they include it in 2013, or better yet, in a service pack. The longer it is allowed to be as it is, the harder it will get to get it changed I guess. And the more code we'll see using it, with bad performance as a result.

[Mr Mike]

I really hope they include it in 2013, or better yet, in a service pack. The longer it is allowed to be as it is, the harder it will get to get it changed I guess. And the more code we'll see using it, with bad performance as a result.

It will not be in a service pack. Service packs are for bugs that have either very low risk in fixing or cause serious problems. This is right in the middle of that spectrum, so it will not be in a service pack.

[JamesMc86]

Thanks for the validation Mads, seems I was misinformed, will have to try it first next time!

[Aristos Queue]

The optimization is *already* in LV 2013. I saw the changelist go through about two weeks ago. This should not be taken as a promise that it will still be in 2013 when all is said and done -- features have been backed out before -- but I think this one is a fairly safe bet.