ashermahonin Performance and Memory
Purpose
Keep performance work honest. Find the bottleneck with evidence, choose the simplest useful intervention, and make sure the result can be measured again.
Change context
- Identify the user-visible or system-visible performance problem.
- Choose the metric: latency, throughput, memory, CPU, allocations, query count, startup, bundle size, or cost.
- Find existing benchmarks, traces, logs, or production signals.
- Name the language/runtime constraints that matter.
Change method
- Form a hypothesis and measurement plan before optimizing.
- Collect baseline evidence or state why baseline cannot be collected.
- Look for algorithmic issues, I/O bottlenecks, query shape, caching boundaries, concurrency limits, allocation churn, and serialization overhead.
- Recommend or implement the smallest change likely to move the metric.
- Re-measure after the change when possible.
- Record tradeoffs: complexity, correctness risk, cache invalidation, resource cost, and rollback.
Engineering constraints
- Use Context7 MCP for current library, framework, platform, API, CLI, and configuration documentation whenever the task depends on external technology behavior.
Evidence
- Performance hypothesis
- Baseline and target metric
- Profiling or benchmark plan
- Optimization recommendation
- Validation evidence
- Language profile update
Ready when
- Never optimize an unnamed metric.
- Do not claim improvement without measurement or a clear reason measurement was impossible.
- Treat caching as a correctness and invalidation problem, not a magic speed button.
- Prefer reducing work over hiding work.
Handoff
Hand off metric, evidence, changed constraints, and regression checks to implementation, QA, or review.
References
references/language-profile-template.md: Use this for language-specific performance notes.