LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Compound Boolean and Numeric Tunnels

So I have a problem between the most efficient way to code iterative operations and the way I usually do it for readability/simplicity



Most efficient.png


Simple and clean


I imagine the last way is way less efficient due to creating a matrix then working through it again.


I'm proposing a merging of these two ideas. A compound tunnel that performs the most efficient method, but doens't mess up my diagrams with a lot of crossing wires and other hard to read messes.




Note, this will only work for commutative functions (add, subtract, and, or, xor... basically anything on the Compound Arithmetic function)


I haven't decided how the selection function should work, so I leave that to the LabVIEW UI coding experts since they've done a good job so far.

LabVIEW CLD (lapsed)
Software is never really finished, it's just an acceptable level of broken
Trusted Enthusiast

IMO, replace those shift registers in your 'Efficient' image with Feedback Nodes and you have efficient and simple and clean.

Active Participant

Excellent point. I actually forgot about that when writing this.


However, I just realized something. Doesn't shift registers and feedback nodes stop parallelism in For loops? This method will allow the best of both worlds. Since it's commutative, it doesn't matter what order they come in and you still avoid creating an array.

LabVIEW CLD (lapsed)
Software is never really finished, it's just an acceptable level of broken
Do you have any benchmarks showing the relative performance benefits? Maybe the feature request should be to optimize the compiler to recognize the clean pattern and refactor.
Active Participant

Huh. Either my test method is flawed, or I might be completely mistaken in my assumptions above.

Register vs Array Add.png

This is adding rand doubles using the two methods.


Welp, this might be knocking my idea out of the sky


LabVIEW CLD (lapsed)
Software is never really finished, it's just an acceptable level of broken
Active Participant

I'm not sure this is a good idea for AND or OR.  Usually, it would make sense to terminate the loop once you get a FALSE (for AND) or TRUE (for OR), and you can easily do that using a Conditional Terminal.  I can see more use for an iterative Add or Multiply, but the code required for this using a SR or Feedback Node is minimal and far more flexible.  Plus I doubt it would prevent users from generating million-element arrays when they're not needed.

Active Participant

As @igagne mentioned, I would strongly recommend programming for readability foremost and only worrying about optimizations when you actually see an issue. In this particular case, there is a very good chance the compiler is already going to recognize those patterns and optimze the code for you. 


Also, the Parallel For Loop does support those numeric and boolean reduction operations. Therefore the post-loop reduction (e.g. build array with summation) or inline reduction (e.g. shift registers with and) would all be parallelizable.

Proven Zealot
Status changed to: Declined