In performance-sensitive hot paths, ensure you (1) don’t repeat expensive work, (2) keep async/event-loop paths non-blocking, (3) bound external operations with finite timeouts, and (4) avoid unnecessary computation/materialization by prefiltering queries and projecting only what’s needed.
Practical rules:
- Probe once, reuse everywhere: if you need media metadata (e.g., audio duration), compute it once per request and pass the result to both upload and downstream message payloads.
- Never run hung external tools without timeouts: wrap subprocess calls (ffprobe, git fetch, etc.) with explicit timeouts and test the timeout path.
- Make conditional SQL/JOINs match output mode: when a “compact” flag is set, don’t select/join/materalize columns you won’t use.
- Eliminate N+1 database scans: prefilter candidates in SQL before loading related rows (e.g., avoid loading all tasks then fetching comments per task).
- Enforce budgets strictly at append/truncation time: check remaining capacity and truncate/reject the next section before adding it, then assert final aggregate size.
- Verify timer/cadence logic with edge cases: clamping must be strictly ordered (e.g., fast-reconnect cutoff must be < stale timeout for all finite stale values) and cadence guards must actually satisfy the stated cadence contract.
- Use hot-path config loaders: in per-turn loops, prefer read-only/minimal-overhead loaders over deepcopy-heavy ones.
Example pattern (reused probe + bounded subprocess):
async def send_audio(path, upload_fn, send_msg_fn, ffprobe_fn):
# Probe once (prefer an async-friendly ffprobe wrapper if available)
duration_ms = await ffprobe_fn(path, timeout=10.0) # must be bounded
# Upload using the same duration metadata
media_id = await upload_fn(path, metadata={"duration_ms": duration_ms})
# Reuse for message payload (no second probe)
return await send_msg_fn(media_id, metadata={"duration_ms": duration_ms})
Checklist to apply during review:
- Does this hot path compute the same expensive thing twice?
- Are subprocess/network/command invocations bounded with finite timeouts?
- Are DB queries prefiltered (no board-wide loads + per-candidate follow-ups)?
- Do query projections/joins change when “compact” or “mode flags” change?
- Are budgets/timers/cadence enforced with strict, testable ordering?
- Are per-turn/per-request utilities using the cheapest available code paths (e.g., read-only config loaders)?