perf!: delta-aware BnbMetric via SelectionView/compute_view

[evanlinjin]

Summary

Makes the branch-and-bound metric evaluator delta-aware, eliminating the dominant cost in run_bnb. A flamegraph showed ~65% of run_bnb_lowest_fee time was spent in cs.selected_value() (47.5%) and cs.input_weight() (17.3%) — both O(|selected|) walks recomputed many times per branch via excess/is_target_met/drain.

Now BnB maintains a per-branch SelectionCache (running aggregates: value_sum, weight_sum, input_count, segwit_count, candidate_count). Inclusion expansions call cache.add(c) — O(1). Metrics receive a &SelectionView<'_> (a handle over &CoinSelector + Cow<SelectionCache>) whose read methods (selected_value, input_weight, excess, is_target_met, drain, …) are all O(1).

Outside the hot path, cs.compute_view() builds a fresh cache once on demand, collapsing the ~15 duplicated O(|selected|) read methods that previously lived on CoinSelector into a single entry point.

Benchmarks

Criterion median; delta-aware vs the bitset baseline, vs the pre-bitset master:

bench	master	bitset	delta-aware	total speedup
clone/4096	5.68 µs	58 ns	52 ns	109×
run_bnb_lowest_fee/20	470 µs	417 µs	158 µs	3.0×
run_bnb_lowest_fee/50	26.0 ms	10.3 ms	5.4 ms	4.8×
run_bnb_lowest_fee/100	73.2 ms	40.2 ms	14.2 ms	5.2×
run_bnb_lowest_fee/200	1.27 s	1.10 s	196 ms	6.5×

The gain is largest at large n, where selected_value/input_weight recomputation dominated. (The n=200 row measures the round-capped exploration path — see the bench commit for the explicit solution-finding vs cap-exhaustion group split.)

Commits

Each commit independently passes the full CI gate (fmt, clippy, doc -D warnings, --release tests, --no-default-features build), so the branch is bisectable.

1. perf!: delta-aware BnbMetric via SelectionView/compute_view — the core change. Introduces SelectionCache/SelectionView, moves the read methods off CoinSelector behind compute_view(), and makes the BnbMetric trait take &SelectionView. Adapted to the current trait API (target passed as a parameter; metric owns its change decision via drain(); Changeless<M>). The cache proptest validates against an independent O(n) oracle (the original input_weight walk), not just a from-scratch cache rebuild.
2. bench: extend pool sizes to wallet (1k) and exchange (10M) scale — also splits the BnB bench into run_bnb_lowest_fee (sizes that find solutions) and run_bnb_lowest_fee_exhaust_cap (sizes where best-first search exhausts the 100k-round cap), with startup assertions pinning which path each group measures.
3. perf: skip unselected scan in BnbIter via per-branch cursor — each Branch carries a cursor into candidate_order, so insert_new_branches jumps straight to the next undecided candidate. The exclusion branch's duplicate-dedup run explicitly skips already-decided candidates (matching the old unselected() semantics) — covered by a regression test with a pre-selected duplicate.

API changes (breaking)

• New public SelectionView<'_>; SelectionCache is internal.
• BnbMetric::{score,bound,drain} now take &SelectionView<'_> instead of &CoinSelector<'_>.
• The read methods (selected_value, input_weight, weight, excess + variants, is_target_met(+_with_drain), fee, implied_fee, implied_feerate, missing, drain_value, drain, effective_value, waste) move from CoinSelector to SelectionView; reach them via cs.compute_view(). is_selection_possible is renamed SelectionView::is_target_reachable.

Review

Beyond CI, this branch went through a 60-agent adversarial review (10 dimensions incl. differential execution of branch vs master vs brute-force exhaustive search over seeded random scenarios; every finding independently verified by 3 reviewers). All confirmed findings are fixed in the commits above. Two pre-existing issues (present on master, not regressions) surfaced and are not addressed here:

• LowestFee::bound's assert!(ideal_fee >= 0.0) can panic on valid inputs due to f32 rounding.
• BnB's exclusion dedup keys on (value, weight) only, treating candidates differing in is_segwit/input_count as equivalent, which can yield slightly suboptimal results vs exhaustive search.

🤖 Generated with Claude Code