Work out the most performant way to do load/save

[coretl]

There are 3 possible approaches to this:

• Make ophyd.v2.SignalRW support Locatable by adding locate() that returns get_value() and the last known put value. Walk the tree of PandA objects, producing all the SignalRW instances as a list. The save plan will emit a single Msg('locate', *signals) message, and return a list of {signal_name: signal_readback} settings. The ordering of this list is Device specific, for PandA, all units must be set in a separate phase before any other signals. The load plan will do an abs_set(signal, group=f"load-phase{phase}", wait=False) for each signal in each phase, then bps.wait(f"load-phase{phase}").
• As above, but the load plan should first do a locate() on everything, and only change the values that are different
• Instead of making a plan, make save and load functions that do the above by calling readbacks = asyncio.gather(signal.get_value() for signal in signals)`` andsignal.put()`

To do this, you need the IOC + ophyd + ophyd-epics-devices PandA setup, then save its setup, then modify 10 or so signals, then load the saved setup back over the top. Do this a few times with the different approaches and measure how long each takes. timeit might be a useful module for this.

[olliesilvester]

Here's what I've found so far:

The saving part for all of these methods takes the same amount of time (~0.14s), which makes sense as that part isn't changing.

Loading a panda configuration by changing every PV takes about ~0.29s, and approximately 0.1s of this is the synchronous waiting that occurs between the two loading phases. Loading the panda by only changing differing PV's when no PV's differ takes ~0.16s . This number gradually increases as the number of differing signals change, with a jump of ~0.1s when there are differing signals in both phases.

There doesn't seem to be any significant difference in CPU loads of the function between all of these methods.

From this, it seems like the best option is the second method (bluesky and ophyd are identical performance-wise) as the load function is almost 2x faster when the PandA is already in the correct state

[coretl]

Thanks for doing this. As the values are similar, I think we will go with the simpler (and hopefully more robust) method of setting every parameter. Although it is a bit slower, it is much faster than all the other things we do in stage (like moving motors and arming detectors)