Repository navigation
Resting-order reads grow quadratically past the resident book cap #621
Description
With many never-filled resting orders, the number of small reads per order keeps rising with the order count once the book is past its resident cap (about 4,000 orders), so total reads grow quadratically.
Measured with test_standing_orders_wall (one never-filled limit order per bar, Release build), reads per order:
| resting orders | 5,000 | 7,500 | 10,000 | 15,000 | 20,000 |
|---|---|---|---|---|---|
| reads per order | 117 | 163 | 194 | 230 | 270 |
Each added 5,000 orders costs about 40-45 more reads per order. Most of the growth is small (8-64 byte) reads of the second id table file.
The test's gating grid currently stops at 15,000 orders; the 20,000-order row is kept in the test file as an open row that refers to this issue, and it returns to the gating grid when this is fixed.
Expected: reads per order stay constant as resting orders grow.
🤖 Generated with Claude Code
Activity
tests: the standing-orders read budget measures against N = 5,000 and…
Combined 1.8.0 batch: scratch caches, live-runner reports, adapter sc…
luisleo526 commentedon Nov 7, 2026
Status: the fix is in review and planned for the 1.11.0 release. This issue stays open until the fix is on main; we will close it then with the commit that fixes it.
Reuse scratch search routes and make native live-object limits exact (#…
luisleo526 commentedon Nov 9, 2026
Status at v1.11.0: v1.11.0 includes bounded reads for resting orders past the resident book cap (#791, commit 33503b8), which removes the slowdown in the cases we gate (5k to 20k resting orders). Whether whole-run reads stay flat in every case is not yet established; that check is planned for v1.11.1. This issue stays open until then.
luisleo526 commentedon Nov 11, 2026
The resting-order read-cost fix is included in v1.11.0 through #791 (33503b8).
Beyond the 4,096-order resident cap, the tested guarantee bounds the additional storage-read work as the order population grows. The regression test uses 5,000, 7,500, 10,000, 15,000 and 20,000 never-filled resting orders, including the restored 20,000-order case. For each adjacent pair it checks real additional read calls and returned bytes per added order against the first interval, allowing at most 9/8 of that reference cost. The existing whole-run 2x growth guard also remains.
This does not require identical total reads divided by total orders: the fixed cost of the resident portion can change that average while the additional cost stays bounded. The five-population checks above are the acceptance criterion for this issue; no further product change is pending for it.