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.
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.
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
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)
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.
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:
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!