How long does this VI take...

[BrokenArrow]

While experimenting with methods to update an array, I intended to check the speed difference when initializing outside the loop vs. inside. While it wasn't surprising that that made no difference, I was surprised at the difference the "zero" timer makes.

Is there a faster way to do this? Oddly, I found using Build Array in the loop (a LabVIEW no-no, I thought) is just as fast as this method, and a little cleaner looking.

Check this VI if you get a chance. My results are written on the BD.

Thanks,

Richard

[ned]

QUOTE(BrokenArrow @ Jan 7 2008, 01:42 PM)

While experimenting with methods to update an array, I intended to check the speed difference when initializing outside the loop vs. inside. While it wasn't surprising that that made no difference, I was surprised at the difference the "zero" timer makes.

Is there a faster way to do this? Oddly, I found using Build Array in the loop (a LabVIEW no-no, I thought) is just as fast as this method, and a little cleaner looking.

Check this VI if you get a chance. My results are written on the BD.

Thanks,

Richard

Looks like my computer is faster than yours - I get 595ms without the "zero" timer and 795ms with the timer.

Build Array should be acceptable in this case because the array is the same size on every iteration, so the memory for it only needs to be allocated once and then it can be reused each time through the loop. You should avoid using Build Array in a loop when you are adding elements to the array on each loop iteration and speed is critical, because adding new elements grows the array. Resizing the array may force LabVIEW to allocate a new, larger segment of memory and then copy all values into that space, which is a time-consuming operation.

[BrokenArrow]

QUOTE(ned @ Jan 7 2008, 05:11 PM)

Looks like my computer is faster than yours - I get 595ms without the "zero" timer and 795ms with the timer.

Build Array should be acceptable in this case because the array is the same size on every iteration, so the memory for it only needs to be allocated once and then it can be reused each time through the loop. You should avoid using Build Array in a loop when you are adding elements to the array on each loop iteration and speed is critical, because adding new elements grows the array. Resizing the array may force LabVIEW to allocate a new, larger segment of memory and then copy all values into that space, which is a time-consuming operation.

Thanks for the test Ned. The speed might also have something to do with Windows running junk in the background, virus-this and nanny-that.

True regarding the Build Array in loop, but VI Analyzer said it was a no-no, whereas the attached VI had no issues. Seems like VI Analyzer would be smart enough to see that it's a set number of elements and not wag the finger at me.

If you had this VI running, say 50 times a second, would you use the "zero" timer or not?

[Rolf Kalbermatter]

QUOTE(BrokenArrow @ Jan 7 2008, 07:49 PM)

Thanks for the test Ned. The speed might also have something to do with Windows running junk in the background, virus-this and nanny-that.

True regarding the Build Array in loop, but VI Analyzer said it was a no-no, whereas the attached VI had no issues. Seems like VI Analyzer would be smart enough to see that it's a set number of elements and not wag the finger at me.

If you had this VI running, say 50 times a second, would you use the "zero" timer or not?

Vi Analyzer is some LabVIEW versions old now and its analysis might have been correct when it was implemented. LabVIEW does make optimization improvements with every new version.

That said Build Array is not a complete no-no. Sometimes there is no way around it or it is in a loop that executes only a few times. But it should always be checked and double checked if you do not want an application that gives you way to much coffee time when it is run.

Rolf Kalbermatter

[ned]

QUOTE(BrokenArrow @ Jan 7 2008, 07:49 PM)

If you had this VI running, say 50 times a second, would you use the "zero" timer or not?

It depends - what else is happening at the time? I remember seeing somewhere that a zero wait allows LabVIEW to yield processor time to other tasks (including other parts of your LabVIEW program), whereas a loop without a wait just runs as fast as possible, consuming all available CPU time. So if you have other tasks executing in parallel then the zero wait is probably a good idea; if you just need that VI to complete as fast as possible, leave it out.

[BrokenArrow]

QUOTE(ned @ Jan 8 2008, 08:30 AM)

...I remember seeing somewhere that a zero wait allows LabVIEW to yield processor time.....

Exactly the reason to include it, and excatly the lament I have whenever someone edits my code and gets rid of the timer because "it was wired to 0 anyway!" :headbang:QUOTE(rolfk @ Jan 8 2008, 06:37 AM)

Vi Analyzer is some LabVIEW versions old now..........

Thanks for that info Rolf, good to know. I do know that the Analyzer has a bad case of OCD, or anal retentiveness.QUOTE(rolfk @ Jan 8 2008, 06:37 AM)

But it [build array in a loop] should always be checked and double checked if you do not want an application that gives you way to much coffee time when it is run.

Coffee time is a huge no-no in this ap. But, as long as it's a set number of indecies, it shouldn't be an issue. I ran the loop 10-million times and it never "slowed down" as the VI Analyzer warned it might.

Thanks for the responses!

===============

OK... I got 27 downloads of the VI so far and only Ned has reponded with a time test.

[Kevin Payne]

QUOTE(BrokenArrow @ Jan 8 2008, 02:05 PM)

OK... I got 27 downloads of the VI so far and only Ned has reponded with a time test.

You can include me among your download count, but as I don't have 8.5 I'm not able to give you any timings!

Kevin

[rpursley]

QUOTE(BrokenArrow)

While experimenting with methods to update an array, I intended to check the speed difference when initializing outside the loop vs. inside. While it wasn't surprising that that made no difference, I was surprised at the difference the "zero" timer makes.

Is there a faster way to do this? Oddly, I found using Build Array in the loop (a LabVIEW no-no, I thought) is just as fast as this method, and a little cleaner looking.

Check this VI if you get a chance. My results are written on the BD.

Thanks,

Richard

I get 505 ms without zero timer

I get 680 ms with zero timer

[TobyD]

QUOTE(BrokenArrow @ Jan 8 2008, 06:05 AM)

OK... I got 27 downloads of the VI so far and only Ned has reponded with a time test.

I get 565ms-585ms without the zero timer

I get 745ms-760ms with th zero timer

This is running on a Core 2 Duo Laptop @ 2.00GHz (667MHz FSB) with 2GB RAM and Windows Vista.

[BrokenArrow]

QUOTE(TobyD @ Jan 8 2008, 11:42 AM)

I get 565ms-585ms without the zero timer

I get 745ms-760ms with th zero timer

This is running on a Core 2 Duo Laptop @ 2.00GHz (667MHz FSB) with 2GB RAM and Windows Vista.

Dang, everybody's computer is faster than mine, which is a Dell desktop, XP, Pentium 4, 2.8 GHz, but only 512MB ram. I'm not a computer expert, but 512MB of ram on a P4 2.8GHz seems like putting Bose speakers on a Conrad Johson tube amp. (and by Bose I mean bad and by Conrad Johson I mean very very good).

[TobyD]

QUOTE(BrokenArrow @ Jan 8 2008, 09:57 AM)

Dang, everybody's computer is faster than mine, which is a Dell desktop, XP, Pentium 4, 2.8 GHz, but only 512MB ram. I'm not a computer expert, but 512MB of ram on a P4 2.8GHz seems like putting Bose speakers on a Conrad Johson tube amp. (and by Bose I mean bad and by Conrad Johson I mean very very good).

I'm glad you explained yourself because I'm not an audiophile and I was about to disagree (I thought Bose was good) but if Bose = Bad = 512MB on XP then I couldn't agree more. You will see a noticeable performance increase if you go to 1 GB. Perhaps not in this application, but in general use you'll notice it. If you switch to Vista I would highly recommend 2 GB.

[Darren]

QUOTE(BrokenArrow @ Jan 8 2008, 08:05 AM)

I do know that the Analyzer has a bad case of OCD, or anal retentiveness.

Here's the description of the Arrays and Strings in Loops test from the VI Analyzer:

Checks loops to see if they contain Build Array or Concatenate Strings functions. Avoid using these functions in loops because each call to them requires a dynamic resizing of the array or string, which can affect memory and processor time. This test does not check Timed Loops.

Although there are cases (as illustrated in this thread) where repeated calls to Build Array inside a loop will not cause a performance degradation compared to other methods, there certainly are many cases where performance will be hindered. As a general rule, the VI Analyzer will point out *potential* performance problems, leaving it up to the user to assess the situation and determine whether the code does in fact need to change.

-D