Jump to content

Loop Indexing


mje

Recommended Posts

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.

post-11742-0-20687400-1346443620.png

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?

post-11742-0-97035300-1346443626.png

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.

  • Like 1
Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.