@jlashner and I have noticed in SAT1 testing at UCSD that over time EPICs calls seem to get slower and slower in ipython sessions. I noticed that this can be fixed by restarting the ipython session. Looking at documentation for pyepics, it appears running caget over and over again like we do currently in pysmurf creates more and more PV objects, each of which is has associated callbacks and other overhead. Looking here : https://cars9.uchicago.edu/software/python/pyepics3/advanced.html they suggest for accessing many channels a number of strategies, including caching PV objects instead of letting caget run wild. Let's try to implement that for psmurf. I will also confirm that all of our caget and caput calls are going through the _caget and _caput wrappers in the smurf_command module.
@jlashner and I have noticed in SAT1 testing at UCSD that over time EPICs calls seem to get slower and slower in ipython sessions. I noticed that this can be fixed by restarting the ipython session. Looking at documentation for pyepics, it appears running caget over and over again like we do currently in pysmurf creates more and more PV objects, each of which is has associated callbacks and other overhead. Looking here : https://cars9.uchicago.edu/software/python/pyepics3/advanced.html they suggest for accessing many channels a number of strategies, including caching PV objects instead of letting
cagetrun wild. Let's try to implement that forpsmurf. I will also confirm that all of ourcagetandcaputcalls are going through the_cagetand_caputwrappers in thesmurf_commandmodule.