namht-perflisted

# namht-perf — measure first, optimize the bottleneck, prove it Blind optimization wastes effort and adds complexity for nothing. The loop is strict: **measure → find the dominant cost → fix that one thing → measure again.** A change that isn't shown to help by numbers gets reverted. (Amdahl's law: only the dominant cost matters — shaving a 2% path is noise.) ## Get a number first (don't guess the hotspot) Ground in the KB (`10-core-flows`, `08-database-schema`) and get real data before changing code: - **DB:** `EXPLAIN` / `EXPLAIN ANALYZE` (MySQL & Postgres) on the suspect query; row counts; index usage. - **Java:** async-profiler / JFR flame graphs; Micrometer timers; Hibernate SQL log for N+1. - **Rails:** `rack-mini-profiler`, the **bullet** gem for N+1, `pg_hero`/`EXPLAIN` for slow SQL. - **Node:** `clinic.js` / `--prof`; DB driver timing. - Or pull real latency/slow-query data from `/namht-observe` metrics + `/namht-splunk-report`. ## The usual dominant costs (and the fix) - **N+1 queries** (a query per row in a loop) → eager-load: JPA fetch-join / `@EntityGraph`, Rails `includes`, a Node dataloader/batch. Usually the single biggest backend win. - **Missing / wrong index or full scan** (`EXPLAIN` shows a seq scan on a big table) → add a targeted or **composite/covering** index matching the query's filter+sort; mind cardinality and write cost. - **Over-fetching** — `SELECT *`, no projection, unbounded result sets → select only needed columns; **paginate**. - **Blo