lobcore

The design choice is the book layout: a bounded flat array of 16-byte levels indexed by tick offset from a per-symbol base, a two-level 64-bit bitmap that finds the best price with one msb/ctz per level so depletion needs no scan, 24-byte order slots in a slab with intrusive FIFO links, and a BTreeMap overflow for every price outside the window. Correctness never depends on the window; only speed does.

Justified against a reference, not asserted

A BTreeMap + VecDeque reference book with an identical API runs the same stream. On the committed 100,000-message synthetic day the array book parses and applies 9.15M msgs/s against the reference book’s 4.80M, a 1.90× ratio of medians over five fresh-process runs on an Apple M1.

That number is reported with its caveat rather than banked: the run’s one-minute load average was 15.15, far above the harness’s 1.0 gate, and repeated batches under load moved the ratio between 1.41× and 2.80×. So neither the absolutes nor the ratio is a result yet. Only the ordering is: the array book was faster in every run of every batch, and an idle re-measurement is owed.

What’s tested

The array book and the reference book return identical events after every operation, and identical snapshots every 64 operations, over proptest sequences. A counting global allocator sees zero allocations across 900,000 in-window messages. The event log and book-state hashes are reproduced by a stdlib-only Python reference on the fixture. The synthetic day’s truth sidecar matches after every one of its 100,000 messages.

What it is not

No matcher yet. No wire path, no thread pinning, and not a production system.