fix(python): use deque for insert-order message queue

[alkasm]

Changelog

Significantly increases the performance of iterating through an MCAP file in insertion order.

Docs

None. (internal only)

Description

I used iter_messages(log_time_order=False) since my application doesn't care about message order, expecting it to perform better than log_time_order=True (the default). However I noticed that my application took 17 minutes to iterate through 3.5 million MCAP messages. It took 32 seconds with log_time_order=True.

The previous message queue implementation used a list as a FIFO queue, which has poor performance as pop(0) will copy the list every time an item is evicted. After changing the implementation to use a deque, log_time_order=False took 15 seconds.

Here's code for a minimal performance test. Note that the mcap file has ~3.5 million messages.

import time
from collections import deque
from mcap.reader import make_reader

with open("example.mcap", "rb") as f:
    reader = make_reader(f)
    start = time.time()
    deque(reader.iter_messages(log_time_order=False), maxlen=0)
    end = time.time()
    print(end - start)

Note that deque(iterable, maxlen=0) will consume the iterable in C, so basically as fast as possible (see the itertools recipe for consume()).

I ran this three times after the fix, but just once before because I didn't have the patience 😄

Before	After
1125.6354639530182	11.093337059020996 10.840037822723389 10.490556001663208

Over 100x faster! If you're curious, log_time_order=True was ~17 seconds (both before and after the changeset).

I also updated the code to have two separate impls rather than a bifurcated implementation.

I added a unit test to assert that log_time_order=False is faster than True (purposely adding messages in reverse log time order so that the heap should perform worse). As with most perf unit tests, it is potentially flakey with smaller inputs so I put 10k messages in it, but feel free to discuss if there's a different way you want to run through that.

[james-rms]

why make an orderable if the collection does not use the comparison operator?

[alkasm]

Good point! I guess log_time_order=False with reverse=True doesn't really make sense? I'll do a ValueError in the factory function then if both are provided. LMK if you think there should be a different approach.