Optimize performance

Treat each optimization as a causal experiment: the cost model predicts, the profile localizes, and the benchmark judges. Preserve correctness and keep complexity inside an explicit budget.

Route the request

• For diagnosis or review, gather evidence and stop after reporting ranked hypotheses unless the user also asks for changes.
• For implementation, run the complete loop.
• For new code without a baseline, classify it as test, application, or reusable library code. Protect test-cycle time and asymptotic behavior; distinguish setup from hot application paths; give library APIs extra design-time scrutiny because later callers inherit their costs and compatibility promises. Compare candidate designs with a cost model and representative prototypes. Prefer the faster design when its complexity cost is negligible.
• For distributed systems, databases, browser rendering, or ML hardware, read the relevant domain skill or authoritative guidance before selecting an intervention. Let it define domain correctness and mechanism constraints; use this loop to govern evidence and verification. When domain guidance is unavailable, deliver the performance contract and evidence plan, then report that boundary.

Read references only when their condition applies:

• Read measurement and experiment design before creating or judging a benchmark, profile, or performance claim.
• Read cost models when estimating without local measurements, comparing designs, or building an environment-specific cost ladder.
• Read diagnosis and hypothesis menu when localizing a bottleneck, choosing a profile, or facing a flat profile.
• Read implementation levers after evidence identifies the dominant cost.
• Read case studies when an implementation lever remains abstract, a flat profile calls for several small improvements, or local and system results diverge.
• Read C++ and Protocol Buffers notes only for relevant C++ or Protocol Buffers code.