DiamondLightSource / DiamondLightSource/scanpointgenerator
Performance limitations of CompoundGenerator::get_point
Open
- Dominant language
- Python
- Stars
- 6
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
Malcolm has started running into problems where get_point is unable to keep up with the pace of scans (now into the kHz range) - buffering can only help so much.
`get_point` has quite a lot of indexing logic to retrieve the values from the component generators based on tiled masks. Can anything be done to simplify this, perhaps by pushing the memory-speed tradeoff made previously further in the "more memory for more speed" direction?
Contributor guide
Assessment
This issue has not been assessed yet.