PullbackContinuation hourly backtest is pathologically slow (38+ CPU-minutes, 5-year window)

[eaitbrahim]

Found 2026-08-17 while measuring hourly trade rates per family: backtest() of PullbackContinuation on a 5-year hourly window (44,537 bars, shipped defaults, market-fill model) ran 38+ CPU-minutes at 100% single-core without completing — versus the same window's turtle backtests finishing in seconds. The measurement had to be killed; the corpus numbers were used instead (so the repo's own records are unaffected — their runs completed on the #257-era engine or with different fixtures).

Suspect: the pending-setup/offset-entry machinery's per-bar scan on long windows (the same machinery #256/#257/#258 iterated on — see strategy/engine.py's pending lifecycle).

Acceptance

• Reproduce: time backtest(PullbackContinuation(...), hourly_candles) on a 1-year and 5-year window; profile the hot loop.
• Identify the complexity class (the 1-year vs 5-year ratio answers quadratic-vs-linear immediately).
• Fix or document the constraint; a tests/ timing pin if the fix lands (a smoke bound, not a benchmark suite — the repo has no perf harness and shouldn't grow one for this).

[eaitbrahim]

Fixed in PR #363 (merged; adversarially reviewed — the exactness core survived an independent golden reproduction plus ~31k-case fuzz with old == new everywhere; the review's two majors — a ts-only cache-validation hole and an 8.5x sliding-window regression from eager state builds — were fixed and re-measured before merge).

Reproduce & classify (acceptance item 1 & 2): deterministic synthetic hourly fixtures, shipped defaults — 8.9s (8,784 bars, 1y) vs 168.6–233.5s (43,800 bars, 5y): a 28.3x ratio on 5.0x bars, squarely quadratic. cProfile: 71% in regime.detect_phase's pivot scans, 26% in indicators.ema_fan — the per-bar full-series recompute over a growing prefix.

The fix (acceptance item 3): _RunningState keeps running values of every full-series quantity (EMA fan, Wilder ATR, phase pivots at radius 1, target swings at radius 2) extended bar-by-bar with the SAME arithmetic and operand order as the pure functions — bit-identical results, O(1) per bar. The turtle-style tail-slice was deliberately rejected: EMA(50) seeded four bars back is a different number than seeded five years back, so a tail would silently re-parameterize the rule. Cache validation is by four anchors (first_ts, length, last_ts, last_close) with an honest docstring about the residual (a mid-series rewrite leaving both anchors identical); state acquisition is LAZY so the bounded condition gate runs first (non-BULLISH bars: 0.012 ms/call, parity with main) and same-window repeat calls never rebuild.

Numbers: 1y 8.9s → 0.19s; 5y 168.6s+ → 2.59s (was 38+ CPU-minutes unfinished on the real window that opened this issue). Trade counts identical (6/22). Correctness pinned by float/Decimal-exact bar-by-bar equivalence tests, rebuild-vs-extend identity, golden backtests captured from main's pre-fix code, anchor-validation and laziness spy tests, and a <60s timing smoke (~270x margin). The repo did not grow a perf harness — one smoke bound.

Not yet deployed — rides the next release cut. The residual 13x-vs-5x superlinearity is the engine's shared per-bar candles[: i+1] slice (all rules), noted in the module docstring; out of scope here.