You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bench: extend pool sizes to wallet (1k) and exchange (10M) scale
The original benches capped at 4k candidates for `clone` and 200 for
`run_bnb_lowest_fee`. Real callers span a much wider range -- a typical
wallet has ~1k UTXOs, a large exchange ~10M.
For the O(n)-ish operations (`new`, `clone`, `compute_view`) extend the
parameter list to 64 / 1k / 16k / 256k / 1M / 10M. These all scale
roughly linearly:
clone/64 51 ns
clone/1024 52 ns
clone/16384 260 ns
clone/262144 2.0 us
clone/1048576 6.3 us
clone/10000000 98 us
At 10M UTXOs the `Candidate` slice itself is ~320MB and the selector's
`candidate_order` Vec is ~80MB -- commented as a heads-up for memory-
constrained hosts.
Add new groups:
- `new`: cost of `CoinSelector::new(candidates)` -- allocations grow with
pool size.
- `compute_view`: cost of building a SelectionView. Scales with
|selected| rather than |pool|; benched against a fixed sparse
selection of ~100 candidates regardless of pool size, matching how
wallets actually use selection.
The BnB bench splits into two explicitly-named groups, because at
n >= 200 best-first exploration does not complete any target-meeting
selection within the round cap (run_bnb returns NoBnbSolution after
exactly 100k rounds):
- `run_bnb_lowest_fee` (n = 20/50/100): end-to-end solution finding.
- `run_bnb_lowest_fee_exhaust_cap` (n = 200/500/1000): exactly
MAX_ROUNDS rounds of frontier expansion (bound() + branch cloning) --
the hot path the delta-aware cache optimizes. Per-round cost grows
roughly linearly:
run_bnb_lowest_fee_exhaust_cap/200 193 ms
run_bnb_lowest_fee_exhaust_cap/500 211 ms
run_bnb_lowest_fee_exhaust_cap/1000 377 ms
Each group asserts at startup that run_bnb's solution-found outcome
matches what the group claims to measure, so a size silently flipping
between the two paths (metric change, bound tightening) fails loudly
instead of corrupting cross-version comparisons.
10M-scale BnB is intentionally not benchmarked: it's impractical at any
finite round budget, and real callers pre-filter / pre-group at that
scale.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
0 commit comments