Showing results for 
Search instead for 
Did you mean: 

Execution speed - feedback node vs. shift register

I stumbled on a blurb recently that suggested that feedback nodes execute more slowly than shift registers.  Since they perform essentially the same function (I see a feedback node as a limited version of a shift register), I would assume that they would compile identically and execute at the same speed.  However, I've run a simple test using the attached VI, and I'm seeing the feedback node typically execute 4 times slower than the shift register!  Is this to be expected?  If so, I guess the feedback node should be avoided in any time-critical apps?
0 Kudos
Message 1 of 10
Ooops...didn't attach vi... trying again.
0 Kudos
Message 2 of 10
Interesting. No explanation, but I see a factor of about 1.6 on my dual 1.8 GHz Mac G5 OS X 10.4.3 and LV 7.1.1 and about 1.4 on LV 8.

0 Kudos
Message 3 of 10


I never use feedback nodes, so I never noticed this.

In a more realistic scenario, we need the output from the last iteration. In this case, the difference is even bigger. Notice that the feedback solution does not have an output similar to wiring from the right shft register and we need to create an output tunnel with indexing disabled.

0 Kudos
Message 4 of 10
Hi Ceger,

This is a good catch, but it has already been reported. The reason that the Feedback Node is slower is because it is NOT just a Shift Register in disguise. It is actually allocating more buffers than the ordinary Shift Register and this is what's causing the added execution time. R&D is currently looking into fixing this so it can match the speed of the Shift Register in future versions of LabVIEW.

Thanks for the feedback though!
- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
0 Kudos
Message 5 of 10

I was curious what the difference between a shift register and a feedback loop were, so I made a little test.

They performed almost identically (at least for 30 seconds). I'm running LabVIEW 7.1.

Here's my test VI. 

Cory K
0 Kudos
Message 6 of 10



When you are trying to benchmark something like this, you don't want anything else going on in your loop.  Cegar's original VI gets the ms value before then allows the loop to run as fast as possible, then gets the ms value again.  Your VI is checking the eleapsed time while you are trying to benchmark the performance.  The elapsed time Vi takes some time to execute.  If it is longer than it takes to perform the operation, then you've masked the actual operation time.  You also have the loops running in parallel, so they are trying to share system resoruces, further affecting your test results.  Cegar's VI will give you a more accurate result because of this.

Message 7 of 10

Oh OK, I see the difference.

I didnt look at his VI before I made mine.

Wow... there is quite a difference between the execution speeds of the two operators 

Cory K
0 Kudos
Message 8 of 10

I realize this is an old thread, but figured since Cory brought it back to life and I never looked at it, I would give some data.  This is using Cegar's VI with Iterations set to 100,000,000 (I saw inconsistent results with it set to the default 10,000,000 - the Shift Register time would drop drastically, almost as if LabVIEW cached it).  This is on a Dell Precision M4300 laptop, Dual Core 2.5GHz 4GB of RAM.


LabVIEW Version      Ratio (Feedback Node/Shift Register)


7.1.1                           2.5

8.0.1                           2.6

8.2.1                           2.6 (but saw peaks in the 3.3 range)

8.5.1                           1.0 (but saw peaks in the 1.25 range)

8.6                              1.3 (but saw peaks in the 1.55 range)


So it appears they must have addressed it some in the 8.5/8.5.1 release, but there appears to have been some degredation in the 8.6 release.


Message Edited by Matthew Kelton on 12-22-2008 12:41 PM
0 Kudos
Message 9 of 10

Just an extra note on Cory's benchmark (Matthew already mentioned some of this)


Cory's benchmark is completely meaningless, because it is way to slow to give any useful result. Most of the time is used updating the indicators and checking the elapsed time. (the "elapsed time" express VIs probably contains a few shift registers themselves!) 😄


.I modified the benchmark as follows:

  • remove all indicators inside the loop.
  • use a simple tick count for the determination of elapsed time.
  • disable debugging.


 Here is the result for a 30 second run under LabVIEW 8.5.1 on my old laptop.


original code:    1153069 +   1165263

optimized code: 238710433 + 239339162 (ratio=1.00263).


As you can see, once you eliminate the extra baggage, the code runs ~200+ times faster! All differences you see are probably due to thread scheduling and which loop shares CPU with the UI thread. In Cory's test, the shift register/feedback node only contributes a fraction of a percent to the total speed. We also have the problem that both run in parallel, so things will differ depending on the number of cores.


Ceger's is a better benchmark, except for the annoying use of stacked sequences. 😮


Shift registers and feedback nodes are not identical in functionality, for example a feedback node (and connecting circular wires) can sit completely inside a case of a case structure, while a shift register must be wired across all the other cases. In newer LabVIEW versions, we also have the "globally initialized" feedback node, whch does not require a loop. There is no equivalent shift register for that. These features make me use the feedback node more and more. They simplify the code!

Message 10 of 10