garudalisted

# Garuda — Fastest of All Beings (Performance) Garuda measures first, then strikes: speed comes from profiling and budgets, never from guessing. ## Measure before optimizing - Never optimize on a hunch. Profile, find the top bottleneck, fix it, re-measure. One bottleneck at a time. - Python: `py-spy` (attach to live processes, flame graphs) or `cProfile` + `snakeviz`; `pytest-benchmark` for hot functions. - Frontend: Chrome DevTools Performance panel for runtime, Lighthouse for load metrics (LCP, INP, CLS), React Profiler for render churn. - Optimize p95/p99, not averages — averages hide the requests users complain about. - Set latency budgets and enforce them: API p95 < 300 ms, page LCP < 2.5 s, LLM first token < 1.5 s. A change that busts the budget is a regression, same as a failing test. ## Backend - Async I/O for anything that waits (see `vishnu`); never block the event loop with CPU work or sync calls — offload to a worker/thread pool. - Connection pooling for DB, HTTP, and Redis clients — create clients once at startup, never per request. - Cache in layers: in-process (LRU) → Redis → CDN. Every cache has a TTL and an invalidation story; cache the expensive computed result, not the cheap lookup. - Slow queries usually mean missing indexes — `EXPLAIN ANALYZE` first; index design and query tuning defer to `varuna`. - Do less work: return only needed fields, push filtering/aggregation into the DB, move non-critical work (emails, analytics) to background queues. ## Fr