Shift register or Local Any differences in performance?

[olifri]

Hallo,

I have a state machine where one state needs to pass and receive from/to
other states.

Should I use a shift register to interchange data or should I take a local
variable? Both work of course but what would you prefer considering

1) Memory usage
2) Performance
3) Readability of source code
4) Good programming style

Thanks for your suggestions

Oliver Friedrich

[Victrick]

From what I understand, using local variables is frowned upon unless they are ABSOLUTELY necessary. In my mind, there is no debate and I would take the shift register. Here are my reasons.

1. I believe that each local variable you have on your block diagram takes up the same amount of space as the original object itself (I'm 99% sure this is correct, can anyone confirm this?). So if you have an numeric indicator that displays a double, and you have 6 local variables linked to that indicator, in terms of memory, you might as well have 7 indicators. If you have one shift register that stores a double value, no matter how many states of your state machine assign values to that shift register, you will only ever have one copy of the data, and only one double

2. Local variables access the data stored in a front-panel control. Depending on what you are using the state-machine for, I think it would be rather unlikely that you want your user knowing what state the machine is currently in. Even if you did, you could wire a front-panel indicator to the shift-register inside the loop to achieve the same effect. I think using a local variable in this situation greatly compromises readability because (likely, again this will depend on the particular state machine) there is no logical association between the state of the machine and the object to which that local variable leads. In other words, the state of the state machine is a property of the block diagram. It doesn't make sense (to me) to use a front-panel object to store a property that will only be read and modified on the block diagram.

I'm talking about state machines in general. These reasons may not apply, depending on your specific application of the state machine (for example, I've often used a tab control in a dialog to simulate a wizard program, guiding the user through some complicated process one step at a time. Each tab of the control corresponded to a different state in a state machine running on the block diagram. In this case, you want the user to know which state they're at. However, that is special case of state-machine)

A general tip is: as tempting as it may be, you never should be using local variable because you want to avoid long wires.

Hope that's helpful

[Ben]

I agree with most everything mentioned by Victrick. Some comments to add.

1) Memory usage
I do not beileve there is a buffer for each local but there indeed are two buffers associated with the FP object. One that you see, one that the BD uses. I believe Greg has mentioned that controls/indicator terminals are just a little more optimized. An ancillary note is that using a property node to write a value is even slower.

2) Performance
Updating or reading from a FP object is something that should only be done when required. If the VI is not a GUI then use controls to get the data, do all of your work in SR's and wires and only when you are done update indicators. In the case of GUI VI's you will have to interact with the FP objects. In this case locals (and terminals) should be used to update the disaplay whenever the app demands. If the GUI object is large (array, etc) then keep a copy in a SR so that you do not have to read the FP object to get the data. Yes, if the user can manipulate the FP object, you are going to have to find out what they wanted by reading from the FP object, no way around it.
So...
What I am trying to say here is that there is some judgement that has to be applied. In the case of a GUI, us studid humans can only grasp image upadtes at about 30 Hz. So 30ms to do something in a GUI is fast enough. If you are number crunching 30ms is slow!

3) Readability of source code
For GUI's I like to be able to search on a FP object to find its locals and terminal to figure how the code is update the object. This lets me look at other developers code and zero in on what could be causing issue, etc. You could take my above suggestions to far and say, "I will use a minimum # of locals, so I will write new data to a SR in 30 different places and then call a case that updates the control from the contents of the SR." This would be a nightmare to trouble shoot. You would ahv eto serach for every case that updated the SR!
I like the idea that if the data in a FP object is questionable, I want to quickly locate the states where the issues could be.

4) Good programming style
Label your wires going to/from SR's.

Trying to help,

Ben