Another long-standing issue for the record...

If you feed multiple chains into the ports of a switch node, only one will be selected for work downstream. But all of them will be evaluated nonetheless.

This is an annoyance when dealing with division by zero. If you have a divide node with a variable denominator that can sometimes be a zero this will trigger a division by zero error. The simple-minded way around this is to test that variable: if it equals zero, provide an alternative value, otherwise let the division proceed.

But this doesn't work. If the value is zero, even though the divide node will not be used, it is still evaluated - thereby triggering the very error you were trying to avoid. The only way around this is to test the variable further upstream which may force you to rearrange other nodes. A puzzle for newbies and a frequent annoyance for daily users like me.

Today I realized, though, that evaluating unneeded branches has another, more serious downside: performance. A node I was building was performing much slower than it should have. This node allows user to chose five options from a menu. Inside the node I pull in various shapes and values, use them to construct all five options, and then use a switch node to choose the option to render.

Each option executed almost instantaneously when the option matched the incoming values. But some options slowed dramatically when constructed using incoming values not intended for that option. I hadn't paid much attention to this because those options would never be rendered. But every time the user chose an option ALL the other options were constructed and then tossed aside, wasted work that, in this case, cause a significant performance hit.

Looking back I see that this happens all the time. Any time you use a switch node you are adding wasted calculations. The more branches you feed into a switch node, the more waste. And sometimes options which are efficient when chosen are very inefficient when not chosen.

A number of users have complained about the slowness of NodeBox compared with other languages. I have wondered at this. In theory, NodeBox should be faster than it is. I now wonder if one factor in this is all those wasted calculations from the unchosen branches of every switch node.

Frederick, if you're still there, did you have some reason for evaluating these unneeded branches? Why not evaluate the index port of the switch node before evaluating anything upstream?

Fixing this might instantly make many of our networks run noticeably faster without any other changes needed.

John