Closed seasonedfish closed 1 year ago
After our discussion today, I wrote a benchmark for fun. Indeed, for the purpose of keeping a deque data structure, the deque
class from the python std is faster. However, I just remembered that I'm only keeping this buffer in memory for visualization - every time a new packet comes, we plot the whole buffer on screen. Benchmarking again and adding a read on the whole buffer every time a new packet comes, the np.array
buffer performs much better, since the elements are stored contiguous in memory and the read is basically free.
[Bench (No access)] BufferDeque(bufsize=1000, n_channels=3, n_packets=1000000) took 0.729s (7.29e-07s/it)
[Bench (No access)] BufferArray(bufsize=1000, n_channels=3, n_packets=1000000) took 1.729s (1.73e-06s/it)
[Bench (with access)] BufferDeque(bufsize=1000, n_channels=3, n_packets=1000000) took 97.989s (9.8e-05s/it)
[Bench (with access)] BufferArray(bufsize=1000, n_channels=3, n_packets=1000000) took 1.771s (1.77e-06s/it)
Ah, thanks for this. Very enlightening, and good thinking about adding a benchmark with a read.
The buffers are fixed-length FIFOs, and they currently use list slicing to update their contents.
We should be able to use deques to achieve this functionality. According to the Python wiki, list set slice has an O(k+n) time complexity, while deque extend has an O(k) time complexity. So, using deques should make the code both easier to understand and faster.