Further SCP Performance Improvements

[mundya]

It occurs to me that if SCP reads and writes used memoryviews much more internally it may be possible to extract further performance improvements.

• [ ] Allow the data part of SDP and SCP packets to be a byte-formatted memoryview - ensure that bytes is called on it prior to creating a bytestring for the packet.
• [ ] SCPConnection.write should accept a byte-formatted memoryview to write and should cast all other arguments into this type before constructing write packets.
  • [ ] MachineController.write should be documented appropriately, and perform memoryview.cast upon any received objects to ensure that they are in an appropriate format.
• [ ] More controversially SCPConnection.read should be replaced with read_into which accepts, instead of a number of bytes, a byte-formatted memoryview to fill with data from the machine.
  • @mossblaser This will affect integration with project-rig/rig-scp - do you have any thoughts here? It may still be possible to use ctypes and return a pointer to a char array from a memoryview, but I'm not sure.
  • [ ] MachineController.read should work a currently, just modified to create a buffer to pass to read_into
  • [ ] MachineController.read_into should be added and should cast the memoryview it receives as appropriate.
• [x] In #115 send_scp_burst should call callbacks with bytestrings/memoryviews RATHER than unpacked packets. This reduce the amount of needless unpacking in the case that none or only some of the SCP fields are used.

[mundya]

NB, because Numpy supports the buffer protocol this should allow:

sdram.write(addr, memoryview(my_numpy_array))

and

sdram.read_into(addr, memoryview(my_numpy_array))  # kwarg for number of bytes, maybe

[mossblaser]

Regarding rig-scp, as you'd expect, the "read" function is really "read-into": you supply a void-pointer into a block of memory to dump the read data into.

All this sounds rather good but I'd be tempted to postpone this until it is really necessary on the old KISS principle. After all, I think at the point where the small differences here make the difference, we're probably stuck anyway. Plus for non (0, 0) writes we're still massively I/O bound anyway. That said, don't let me block a weekend of fun ;).