Sydnee nightly — performance audit — 2026-06-06 P0 findings: 0 P1 findings: 0 Risks: 3 - Area: Performance (Saturday theme) - Branch: `dev` (371b98c) - Files scanned: `bot.py` (18 489 lines), `core/database.py`, `pages.py`, `docs/strategy_decisions.md`, prior audit chain (2026-05-30, 2026-05-23) - Bugs found (P0 / P1): 0 / 0 - Risks noted: 3 (1 new, 1 extended carry from 2026-05-30, 1 long carry from 2026-05-23) --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-06-06_performance.md Reply FROM [email protected] to [email protected] to request fixes, e.g.: "code_task on sydnee-signals-dev: apply fix for the P0 about RVOL threshold in bot.py" Sydnee Agent will propose + you APPROVE (or plain 'approve') + auto-push to dev. --- Full audit below (first 12 KB) --- # Nightly Audit 2026-06-06 — PERFORMANCE ## Summary - Area: Performance (Saturday theme) - Branch: `dev` (371b98c) - Files scanned: `bot.py` (18 489 lines), `core/database.py`, `pages.py`, `docs/strategy_decisions.md`, prior audit chain (2026-05-30, 2026-05-23) - Bugs found (P0 / P1): 0 / 0 - Risks noted: 3 (1 new, 1 extended carry from 2026-05-30, 1 long carry from 2026-05-23) --- ## Findings ### RISK (new): `_scalp_signal_log_loop` — duplicate `hgetall` per symbol per tick after e1981c3 **File:** `bot.py:16454` (pending-event scan), `bot.py:16492` (new-event scan) **Evidence:** ```python # bot.py:16447-16457 — per-pending-event fetch, called once per event per tick: for ev in pending: ... eh = r.hgetall(f"signals.poly.live.{ev['symbol']}") # line 16454 snap = self._tape_score_sym(ev["symbol"], eh, None, now_ms) # bot.py:16490-16495 — symbol scan, also fetches same keys: for sym in syms: h = r.hgetall(f"signals.poly.live.{sym}") # line 16492 res = self._tape_score_sym(sym, h, prev.get(sym), now_ms) ``` At steady state with `SCALP_SIGNAL_LOG=true` and 8 symbols × `_SCALP_HORIZONS=(30,60,120,300)`: - Max pending depth: `floor(300s / 60s cooldown) × 8 syms = 40 events` - Per 2-second tick: 40 hgetall calls (pending) + 8 calls (scan) = **48 total** - Unique keys needed: **8** → 6× redundancy at max depth The pending-event comment at line 16449 acknowledges "one redis fetch + one score" per event but does not deduplicate across events that share the same symbol. This pattern was introduced by the exit-research redesign in commit e1981c3 (2026-05-31), which added per-event MFE/MAE tracking and per-horizon snap calls requiring a fresh tape snapshot each tick. **Impact:** Low today — Redis is localhost Docker (<0.1 ms/call), so 48 calls adds ~5 ms of latency per 2s tick (0.25% overhead). Risk materialises if Redis moves off-host or if the symbol set expands significantly. No data-correctness concern. **Fix:** ```python # At the top of the while loop body, pre-cache hgetall by symbol before either loop: _sym_hashes = {} for _sym in sorted(set(self.symbols)): try: _sym_hashes[_sym] = r.hgetall(f"signals.poly.live.{_sym}") except Exception: _sym_hashes[_sym] = None # Replace bot.py:16454 in the pending loop: eh = _sym_hashes.get(ev["symbol"]) # Replace bot.py:16492 in the new-event loop: h = _sym_hashes.get(sym) ``` Collapses 48 calls to exactly 8, regardless of pending depth. --- ### RISK (extended carry from 2026-05-30): `api_scalp_signal_summary` + `api_scalp_signal_horizons` — no response cache; unbounded `count(*)` in summary **File:** `bot.py:14466-14477` (summary, no cache), `bot.py:14479-14496` (horizons, no cache); `core/database.py:393-430` (summary queries), `core/database.py:432-465` (horizons queries); index: `database.py:331` (`idx_scalp_log_ts ON scalp_signal_log (ts)`) **Evidence:** ```python # bot.py:14467 — summary: no cache guard, 3 raw queries per call: def api_scalp_signal_summary(): ... return jsonify(self.db.scalp_signal_summary(hours=hours) or {}) # bot.py:14479 — horizons (new since 2026-05-31): no cache guard, 4 raw queries per call: def api_scalp_signal_horizons(): ... return jsonify(self.db.scalp_horizons_summary(hours=hours, min_score=min_score) or {}) ``` ```python # database.py:426 — unbounded count(*) in scalp_signal_summary: cur.execute("SELECT count(*)::int AS total FROM scalp_signal_log") # No WHERE clause → full sequential scan, grows O(N) with table lifetime. # database.py:444 — scalp_horizons_summary WHERE has ts + score + IS NOT NULL: WHERE ts >= now() - make_interval(hours => %s) AND score >= %s AND ret_{hsec}s IS NOT NULL # idx_scalp_log_ts covers ts filter; score + IS NOT NULL require heap-scan. ``` A single page load of the scalp research page fires **both** endpoints: 3 + 4 = 7 GROUP BY queries, plus one unbounded sequential scan. None are cached. With `SCALP_SIGNAL_LOG=true` accumulating data at ~120 events/hour (8 syms × 1/60s × 3600), after 2 weeks the table holds ~40 000 rows. The `count(*)` will read all 40 000 rows every summary call regardless of the `?hours=` window. Neither endpoint is currently auto-polled by the dashboard (no reference in `pages.py`), so impact is limited to manual research page loads today. **Fix:** ```python # bot.py — add 30-second response cache mirroring _perf_cache pattern (bot.py:13062-13063): _scalp_summary_cache: dict | None = None _scalp_summary_cache_time: float = 0 _scalp_horizons_cache: dict | None = None _scalp_horizons_cache_time: float = 0 # Inside api_scalp_signal_summary(): now = time.time() if self._scalp_summary_cache and now - self._scalp_summary_cache_time < 30: return jsonify(self._scalp_summary_cache) result = self.db.scalp_signal_summary(hours=hours) or {} self._scalp_summary_cache, self._scalp_summary_cache_time = result, now return jsonify(result) # Inside api_scalp_signal_horizons() — same pattern with _scalp_horizons_cache. ``` ```sql -- database.py — replace unbounded count(*) with time-windowed count: cur.execute( "SELECT count(*)::int AS total FROM scalp_signal_log " "WHERE ts >= now() - make_interval(hours => %s)", (hours,)) -- Uses idx_scalp_log_ts; stays O(window size), not O(table lifetime). ``` --- ### RISK (carry from 2026-05-23): `pd.concat + iloc[-500:]` double-alloc GC pressure in bar handlers **File:** `bot.py:2942`, `bot.py:2963`, `bot.py:3092` **Evidence (unchanged from prior audits):** ```python ss.bars[1] = pd.concat([ss.bars[1], new_row_1m]).iloc[-500:] # bot.py:2942 ss.bars[tf] = pd.concat([ss.bars[tf], new_row]).iloc[-500:] # bot.py:2963, 3092 ``` Each bar event allocates a new DataFrame (concat), then immediately discards a slice (iloc). At 8 symbols × 5 TFs × ~12 events/min: ~480 alloc+GC cycles/min. Unchanged since filing. Low severity at current scale; no failure mode. --- ## OK (checked, working or recently fixed) **`_scalp_signal_log_loop` False-sentinel P1 (from 2026-05-30) → RESOLVED:** Commit e1981c3 redesigned the horizon-snapshot loop to use `_snapped_{hsec}` flags (bot.py:16469, 16479). Flag is set unconditionally for any elapsed horizon (inside `for hsec in horizons` loop, outside the `if snap is not None:` block) — stale-tape events are correctly finalised without retry. The double-write / wrong-horizon bug is closed. ✓ **`api_nav` 5s response cache:** confirmed at `bot.py:12717-12718`. `_nav_cache` + `_nav_cache_time` guard short-circuits the two uncached DB queries when interval < 5s. ✓ **`_perf_cache` 30s TTL:** confirmed at `bot.py:13062-13063`. All `/api/performance` calls within the same 30s window return cached payload. ✓ **Tape Scanner poll slowed 2.5s → 5s:** commit 5fde507 reduced `tape_scanner_poll` interval from 2.5s to 5s, halving the `/api/tape-scanner` call rate and its per-call scoring overhead (8 sym × `_tape_score_sym`). ✓ **TV-BXT scale-in redesign (3b0d6ac) — no new perf regressions:** `_tv_scale_step` calls `self.open_trades()` (in-memory list filter, bot.py:1199-1201) twice per slot-2..10 evaluation (lines 4273, 4287). With n<<10 open positions at any time, this is O(n) over a negligible list. The `_regime_redis.get(f"tv_bxt_signal_ts:{sym}")` at bot.py:4206 is a single lightweight GET per call. No new hot-path regression. ✓ **`_scalp_signal_log_loop` pending list size bound:** at 8 symbols, 60s cooldown, 300s max horizon, max pending depth = 8 × floor(300/60) = 40 events. In-memory footprint ~7 KB (40 events × ~180 bytes each). Negligible. ✓