Almost every time I see a someone write an LV2-style global (you know, an uninitialized shift register on a loop that is guaranteed to run exactly once, used to store data for retrieval on a later call), it is written with a While Loop, with a constant wired to the Stop terminal. I've always written mine with a For Loop with a constant 1 wired to the N terminal. It seemed more intuitive, and for some reason I felt LabVIEW might optimize it better, since normally the contents of a While Loop cannot be optimized based on number of times it'll execute, but a For Loop always can.

So I asked Jeff K (father of LV, deep knowledge of diagram optimization). He says that we can indeed constant-fold a While Loop with a constant wired to the Stop terminal. It's the only time we can constant fold the contents of a while loop, but we can do it. He says that there's no advantage to using one over the other.

It answered a nagging question in my mind. I thought others might be interested as well.

I honestly never thought of using a for loop. I always used a while loop since the beginning of time. What's even more curious is that of all the LabVIEW programmers I've interacted with, not even once has anyone brought this point up. I'm not trying to suggest that your implementation is invalid or any less worthy. I'm just shocked that this is the first time I've come across this. Learn something new everyday, I guess.

I prefer not to use loops, at all -- just use a unowned (floating) feedback node.



 unowned_feedback_node.vi ( 8.06K ) Number of downloads: 310

I tested this particular issue a month back while I was working on a piece of code that would use in everywhere. The result was that while loop indeed is faster than for loop for this particular task. I didn't figure out why, after all I don't have deep knowledge of diagram optimization like Jeff K does.

Tomi

I usually use while loops...

Question to AQ:
I have a Functional Global "Array of Cluster" always 50 Elements.

Why is the "write" faster than the "read"?

The feedback node concept is nice, but I wonder why I see a warning sign.
I always have warnings on by default.
Strange thing in this case is, that the error/warning dialog shows a warning for the VI but no details about it given.

James,
Interesting use of the feedback loop. This use doesn't seem to be covered in the LabVIEW documentation at all.
Could you elaborate slightly as to what is going on?
Thank you.
Jon

---
Never mind. My calendar must be off by a couple of days due to the new daylight savings time.
---

This post has been edited by Jon Sweeney: Mar 29 2007, 05:06 PM

I do not remeber which verion of LabVIEW it was but I benchmarked the performance of the For vs While thinking that I could pick up some speed with the For loop.

To my suprise the While loop won.

Another point (that I was planning to cover in a future Nugget) is that AE do not have to limit themselves to a single iteration.

Example:

In order to "shoe-horn" an app into a FP 2000 I needed to be very careful with my memory usage. By using an AE that could call itself, all of the analysis could be performed with the data residing in the SR. It sorta works like a "state machine" with multiple entry states.

SInce the actual proccessing required depended on the data, I could not tell before the AE was called, how many steps would execute.

So...

Using a while loop allowed me to adapt without replacing the while with a for.

Just my thoughts,

Ben

Hmmm... Just looking at the scrollbars there is a hint that the diagram is larger than what is shown...
Anything hidden in the 5th dimension, Jim?

These Q are generally best answered by looking at the code and examining the buffer re-use.

Are both the Control an Indicator on the root of the diagram?

Ben

Do you have the VIs that you used for the benchmarking? These would be useful to investigate.

I did one with a FOR loop once, quite a while back. The application was a sort of Tag list, which was rather large, but the individual reads and writes were allowed to be sparse arrays. The actual read or write variable was a cluster of