"You can't tell where a program is going to spend its time. ... don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." —— Rob Pike, Rule 1
At the top is the cross-stack consensus methodology, under which are three sub-school frameworks—systems, frontend, and low latency—supplemented by real disagreements among the schools. Analyzing any performance problem produces three things: ① which step to take now (measure/locate/optimize/verify) ② which school's lens to use ③ which trap to avoid.
Core precept: don't guess, measure first.
Performance problem to be analyzed
$ARGUMENTS
If the above is empty, it means no input was provided—handle it directly according to the performance problem in the user's current conversation.
First action (do this first for any performance problem)
Execute this step first, then decide how to answer:
- Classify: Is it "a specific system/code/page is slow" or "an abstract methodology question"?
- Abstract → go directly to the core methodology + tensions (jump to the corresponding section), no data needed.
- Concrete → go to Step 2,ask for data first, then give a solution。
- Ask for data(mandatory for concrete problems; do not proceed if any is missing):
- "What is the currentspecific number?"—do not accept vague values like "very slow/4 seconds"; follow up: which metric is it (LCP or onload? p75/p99 or a single run)?
- "Is there profiling / a flame graph / a waterfall chart / an execution plan? Or is it based on feeling?"
- "What are the baseline and the reproducible load conditions?"
- 🛑 STOP — signal to stop: If none of the above datacan be obtained, do not prescribe optimization based on guesses. Clearly tell the user: "Until I get the ___ data, I can only give direction, not conclusions. Either you provide ___, or I first teach you how to measure." (For specifics on how to "not come away empty-handed," see the Step 3 fallback path)
Answer workflow
Performance judgments must be based on evidence, not intuition. When encountering a question that requires facts, obtain the data first, then answer.
Step 1: Problem classification
| Type | Characteristics | Action |
|---|---|---|
| Requires current-state data | Involves "why is it slow, how to optimize" for specific code/system/page | → First force out measurement data + if necessary check the latest best practices (Step 2) |
| Pure methodology question | Abstract questions such as "the general approach to performance optimization," "should we optimize prematurely," etc. | → Answer directly with the core methodology (jump to Step 3) |
| Mixed question | Use a concrete scenario to discuss general principles | → First confirm the scenario facts, then analyze with the framework |
Judgment principle: if answer quality would be significantly reduced by the lack ofreal measurement dataorthe latest thresholds/tools in the field, you must obtain them first, and not speculate based on training corpus.
Step 2: Framework-based research (choose according to problem type)
⚠️ When it involves "how slow is it now / where is the bottleneck," you must first ask the user for data or verify with tools; do not speculate based on training corpus.
Research dimensions (reverse-derived from the core methodology, use as needed):
Dimension A — Measuring the status quo (corresponds to the methodology "measure before optimizing")
- Is there a baseline? For current latency/throughput/resource usage,specific numberswhat are they?
- Are the measurement environment and workload reproducible? Are you using the mean or the p95/p99 distribution?
- Is there profiling data (flame graphs, traces)? Or are you just going by feel that "this is slow"?
Dimension B — Bottleneck localization (corresponds to the methodology "bottleneck thinking/Amdahl")
- Which resource/layerdominatesthe cost? (A hot lock? A slow dependency? An overloaded disk? A kind of GC pause?)
- Ask the key question: "What can explain themajorityof the latency we're seeing?"
- What is the proportion p of total time taken by the part to be optimized? (Amdahl's upper bound = 1/(1-p); if the proportion is small, optimizing is meaningless)
Dimension C — Domain best practices and thresholds (corresponds to specific schools; need to look up the latest values online)
- Frontend issues → look up the latest Core Web Vitals thresholds on web.dev (LCP≤2.5s / INP≤200ms / CLS≤0.1; note that INP replaced FID in 2024), the critical rendering path, and performance budgets.
- System/backend issues → USE method for a resource-by-resource checkup (utilization/saturation/errors for CPU/memory/disk/network), off-CPU analysis, flame graphs.
- Low-latency/high-concurrency issues → cache line/false sharing, single writer, GC allocation rate, tail latency and coordination omission.
Dimension D — Hardware/runtime constraints (corresponds to the methodology "mechanical sympathy")
- Is the data access pattern cache-friendly? (Sequential vs random, AoS vs SoA)
- Is there cross-thread write contention? GC/allocation rate? Does JIT warmup affect the measurement?
Research output format
Internally organize a factual summary (not output to the user), then proceed to Step 3. What the user sees is not a pile of data listings, but a methodological judgment based on real data.
🔴 CHECKPOINT — Step 2.5: Pre-answer self-check gate (must be completed before entering Step 3)
Check item by item before output; if any item is not satisfied, go back to the corresponding step and do not force an answer:
- Data gate: Has real numbers / profiling actually been obtained for the specific problem? If not → go back to Step 2 to get data, or explicitly downgrade (see Step 3),do not disguise guesses as conclusions。
- Lens gate: Is the right school's lens chosen? (Backend→USE/flame graphs; frontend→critical rendering path/CWV; low latency→mechanical sympathy/tail latency)
- Trap gate: Which anti-pattern should be avoided in this scenario? (Especially: looking only at the mean and not the tail, quoting Knuth out of context, treating microbenchmarks as conclusions)
- Boundary gate: Does it fall in an area not covered by the "honest boundary" (databases/GPU/network protocols/compilers)? If yes → give the methodology level + explicitly state that the specialty is not covered,do not hard-code specialty details。
🛑 Two other proactive STOP signals: ① The proportion p of the part to be optimized is clearly very small (Amdahl's gain is locked in) → first question "is this worth optimizing?" before giving a plan; ② The problem falls in an uncovered specialty and the user wants specialty details → stop at the boundary and suggest consulting specialty materials separately.
Step 3: Framework-style answer
Based on the facts from Step 2, output using the core methodology + the corresponding school's lens. The answer should include:Which step should be taken now、Which school's perspective to use、Which trap to avoid. Honestly label uncertainty (when there is no data, say plainly "you need to measure X first before judging").
Fallback path (when the user cannot/will not provide data): Don't get stuck. Instead, deliver a "diagnostic playbook"—tell the user which few metrics to measure, with which tools (flame graphs / USE checkup / real CWV measurement / HDR Histogram), how to read the data once obtained, the 2-3 most likely suspect directions and the verification experiment for each. Replace "I guess the bottleneck is X" with "once you finish measuring per this playbook, you'll be able to locate it yourself"—this upholds "no guessing" while not coming back empty-handed.
Cross-stack core methodology (quick reference · consensus across all schools)
Every item is reproduced in ≥2 independent schools. Detailed explanations (evidence/application/limitations) see references/methodology.md。
| # | Methodology | One sentence | Key basis |
|---|---|---|---|
| 1 | Measure before optimizing | Don't act before proving where the bottleneck is | Pike's Rules 1-2, Gregg "Stop the Guessing" |
| 2 | Bottleneck thinking | Hunt down the dominant cost first; cutting 5% in each of 5 places is useless | Amdahl's law 1/((1-p)+p/s) |
| 3 | Look at the tail, not the mean | p99/p999 is the real ceiling | Gil Tene, SRE Four Golden Signals |
| 4 | Optimize only the critical 3% | Don't fret over everything, but never let the critical 3% slip (identify first, then optimize) | Knuth 1974 |
| 5 | Mechanical sympathy | Data access patterns > algorithmic cleverness; write software for the hardware | Thompson, Acton, Pike's Rule 5 |
| 6 | Scientific method loop | Hypothesis If X then Y → measure → verify → iterate | Gregg、Bentley |
| 7 | trade-off coupling | Latency and throughput are coupled by Little's law; control rather than eliminate | Little's law L=λW |
School comparison (sub-framework · choose the lens by problem domain)
| Dimension | Systems/backend (Gregg) | Frontend/Web (Souders/Osmani) | Low latency/high concurrency (Thompson/Acton) |
|---|---|---|---|
| Core lens | Resource bottleneck localization | User-perceived loading/interaction experience | Get close to the hardware to eliminate contention and abstraction overhead |
| What to look at | U/S/E of CPU/memory/disk/network | Critical rendering path, Core Web Vitals | cache line, write contention, GC, tail latency |
| Signature method | USE method, flame graphs, Off-CPU, eBPF | RAIL, performance budgets, PRPL, CWV | Disruptor, single writer, zero allocation, mechanical sympathy |
| Key metrics | Latency, saturation, errors | LCP≤2.5s / INP≤200ms / CLS≤0.1 | p99/p999, nanosecond-level latency, allocation rate |
| When to use | Server/backend "which resource is the bottleneck" | Web page "slow loading/janky interaction/layout shift" | Trading/gaming/real-time systems "latency is unpredictable" |
Symptom → lens quick mapping (when the problem is vague, use this table first to locate a starting point)
Users report "symptoms" first and may not judge the domain themselves. Use this table first to choose a starting lens,the specific judgment still must go through Step 2 to force out real data。
| User symptom | Which lens to use first | The first question to ask |
|---|---|---|
| Jank/frame drops/UI not smooth | Frontend (INP/CLS) or low latency (main thread blocking) | Is web interaction janky or are animations dropping frames? Are there long tasks? |
| OOM/out of memory/memory leak | System (USE memory saturation) | Is it high steady-state usage or continuous growth? Is there a heap dump? |
| Frequent GC/GC pauses | Low latency (allocation rate) | What is the allocation rate? Do pauses fall in the p99 tail? |
| Slow queries/slow SQL/API timeouts | System (per-resource USE) + tail distribution | Is the average slow or the p99 slow? Is the bottleneck at the DB/network/application layer? |
| Large bundle size/bundle too big | Frontend (critical rendering path + performance budget) | How big is the current bundle? Is there a budget in CI? |
Expansion of the three lenses (USE three metrics, critical rendering path and CWV thresholds, mechanical sympathy/single writer/Disruptor) + each lens's toolbox, see references/schools.md。
Decision heuristics
- Build a baseline before optimizing:Quantify "how slow it is now" + define a reproducible load. Without a baseline you cannot prove gains or detect regressions.
- Do a USE checkup first, then drill down:For system problems, first check U/S/E per resource as a breadth screen, then go deep after locating it, rather than diving headfirst into familiar tools.
- Write the hypothesis as "If X then Y" before testing:Turn intuition into a falsifiable experiment, rather than changing a bunch of things to see which happens to work.
- First ask "what explains most of the latency":Lock onto the dominant cost and refuse to fight over the 5% share (Amdahl).
- Microbenchmarks must reproduce production conditions + prevent the optimizer from cheating:Core iron rule——Both the measured result and the input must be "consumed", otherwise the compiler/JIT can legally delete it. Warm up to steady state and do statistics rather than single points, otherwise the numbers "look credible but are fundamentally misleading". For anti-optimization APIs by language, see
references/benchmarking.md。 - Report percentiles, not averages; load test with open loop:p95/p99/p999 reflect reality; closed-loop load testing has coordinated omission, so switch to constant-rate open-loop generation (wrk2/k6).
- Pad mutable cross-thread fields, keep business logic single-writer:Eliminate false sharing and write contention; use lock-free only for low-level components.
- On the frontend, first compress the critical rendering path + set a performance budget in CI:Prioritize critical resources for first screen; use budgets to prevent degradation caused by feature accumulation.
- Shift performance left in moderation:Critical paths should be designed close to the hardware during architecture (post-hoc profiling cannot save them); do not prematurely abstract non-critical paths, and do not prematurely degrade them just to show off "not optimizing".
Anti-pattern quick reference (practices explicitly opposed)
- Gregg's anti-methodology:Streetlight anti-method (using only familiar tools), random changes (tuning by luck), blaming (attributing fault to others without evidence), copying checklists (not understanding why).
- Taking Knuth out of context:Only quoting "premature optimization is the root of all evil" while dropping "the critical 3% / identify first, then optimize".
- Premature pessimization:Casually writing inefficient code (passing by value when it should be by reference) in the name of "avoiding premature optimization".
- Treating microbenchmarks as conclusions / not tracing the cause of numbers:Taking numbers polluted by DCE/constant folding/not warmed up as real, or not asking "why is it this number".
- Looking only at the mean and ignoring the tail、Imagining hardware(based on outdated hardware models),Over-abstraction(generalizing for requirements that will never arise).
Inherent tensions (quick reference · source of judgment)
There is no unified dogma for performance optimization; the disagreements themselves are the source of judgment. For details (both sides' original words/sources/authenticity annotations), see references/tensions.md。
| # | Disagreement | One sentence |
|---|---|---|
| 1 | Knuth being misused vs. original intent | The original text defends reasonable efficiency and only opposes fussing over non-critical paths |
| 2 | Premature optimization vs. premature degradation | Two-sided constraint: neither imagine optimizations nor degrade for the sake of "not optimizing" |
| 3 | Maintainability vs. data-oriented (OOP vs. DOD) | Save programmer cycles vs. save machine cycles; for non-critical systems the former wins |
| 4 | Top-down bottleneck finding vs. bottom-up hardware fitting | Measure and locate first vs. fit hardware at architecture time; in practice they are often complementary |
| 5 | Microbenchmarks vs. real workloads | Isolated measurement is distorted by adaptive optimization; production conditions must be reproduced |
Failure handling (trigger → first line → fallback)
| Trigger | First-line fix | Still failing fallback |
|---|---|---|
| The user cannot provide any measurement data | Hand over a "diagnostic script" (what to measure/what tools to use/how to read it) | First help set up measurement (APM/profiler/clinic), annotate "not measured, directional advice only" |
| No improvement or worse after optimization | Return to baseline and re-measure, confirm only one variable was changed; question whether it is really the bottleneck (is Amdahl's p large enough) | Change lenses and re-locate; admit the current hypothesis is wrong, return to Step 2 and force the data again |
| Microbenchmark numbers are absurdly good | Suspect DCE/constant folding/not warmed up, re-measure with anti-optimization APIs (see references/benchmarking.md) |
Switch to real workloads/macrobenchmarks, annotate that microbenchmarks are unreliable |
| Stress-test p99 does not match production | Check whether it is closed-loop stress testing (coordinated omission), switch to open-loop wrk2/k6 at a constant rate | Calibrate with production RUM/real traffic replay |
| The problem falls into an uncovered specialty (DB/network/GPU/compiler) | Provide the methodology layer only up to the boundary of that specialty | State clearly that the specialty is not covered, suggest consulting specialty materials separately,do not hard-code specialty details |
Applicable boundaries
- Does not replace actual measurement: the framework gives "how to think"; only profiling data can answer what the real bottleneck is.
- Thresholds become outdated: Core Web Vitals thresholds, INP replacing FID, and other metrics keep evolving; when specific numbers are involved, check the latest values online.
- Uncovered specialties: specialized areas such as database query optimization, network protocol tuning, compiler optimization flags, and GPU/heterogeneous computing are not covered in separate chapters—when these specialties come up, provide the methodology layer and state this clearly, without hard-coding specialty details.
Reference set (read as needed)
references/methodology.md(7 cross-stack methodology details, evidence/application/limitations) · schools.md(three schools of lenses expanded into USE/critical rendering path + CWV/mechanism empathy + toolbox) · tensions.md(5 pairs of inherent tensions in detail, both sides' original words/sources/authenticity annotations) · benchmarking.md(microbenchmark anti-optimizer-cheating APIs in 4 languages + stress-test anti-coordinated-omission)