feedback node global

[PaulG.]

Were these just a fad? I stopped using them years ago because I heard they had performance problems. But I also heard that they were not intirely implemented correctly and NI was going to fix it.

[RavensFan]

I haven't heard of any problems with them.

I tend to use the classic while loop, shift register, True wire to stop terminal version of a functional global.  But the feedback node method is generally functionally similar.

[tst]

For the example that you gave, you might as well use a global variable.

Feedback nodes were said to have some performance problems when they were introduced in 7.0, but I believe that since ~8.0 they should be fine. I certainly don't have problem with them and since the addition of the free-standing FN in 8.5 they have helped simplify some of my code. I would still use a while loop if I think that a shift register makes the code more readable.

The only later performance issue I'm aware of is that if you have a variant in a FN and you wire an empty variant to the init terminal, then you might run into some serious performance problems, but that was fixed in 2010 (or possibly 2011).

[bsvare]

They are almost identical (Feedback is about 4-5% slower in my timing compairison tests) However, I've never noticed that having any impact on the code I write.

Instead, I've noticed that it can make significant impact on block diagram complication. I use to have a 1000 pixel wide loop with 4 or 5 wires always being wired through, now I can get rid of most of them (they were only used in one location each) and the block diagram appears a lot cleaner.

[JÞB]

I have been playing on a AE twist that uses the FBN for private data where the resource API has standard Error in functionallity.  I can clear two sync barriers (the error case and the while loop) and improve "Close" functionallity so that close on error in is attempted.  No, I don't think its a fad..... just not fully understood where they can provide benefit.

[Darren · Accepted solution]

[crossrulz]

I remeber doing a test not long ago and found that the FBN was slightly slower than the SR for creating FGVs.  I'll have to test it again with the lastest LabVIEW version.  I do remember back in the 8.6 days of Darren stating the the FBNs were faster due to not needing the loop overhead.  So a lot of my FGVs use feedback nodes.  I think they make it cleaner.  Some I work with think the SR is easier to understand.

[Darren]

I've noticed the benchmarks tend to flip-flop between LabVIEW versions, depending on whatever changes/optimizations were made to the compiler. But with every release in recent memory, the benchmark differences have always been very small either way. So I consider the two approaches to have effectively the same performance, and thus, I prefer the feedback node approach...I find the code simpler and more readable.

[JÞB]

---

@crossrulz wrote:

I remeber doing a test not long ago and found that the FBN was slightly slower than the SR for creating FGVs.  I'll have to test it again with the lastest LabVIEW version.  I do remember back in the 8.6 days of Darren stating the the FBNs were faster due to not needing the loop overhead.  So a lot of my FGVs use feedback nodes.  I think they make it cleaner.  Some I work with think the SR is easier to understand.

---

There is simply no visable indication of how the initiallize terminal is configured in a FGV.  Of course this obfuscates the code.  I'm sure there is a IE post on it somewhere if there isn't a CAR written against this.