CONCEPT Cited by 4 sources

Hot path

The hot path is the code that runs on every (or near-every) request, especially at high request rates. It's the call chain whose per-invocation cost is multiplied by the request rate and shows up directly in p50/p95/p99 latency and total CPU.

Why it's the unit of optimization

• At 1k req/sec, a 1 µs helper costs 1 ms/sec of CPU — 0.1 % of one core. Nobody cares.
• At 1M req/sec, the same 1 µs helper costs a full core.
• At 35 M req/sec (the pingora-origin scale), a 1 µs helper costs 35 cores; a 4 µs helper costs 140 cores.
• A seemingly-trivial one-line helper (clear_internal_headers) was 1.71 % = ~680 cores.

At CDN scales the hot path is the only place where engineering micro-optimization pays real dividends — cold-path work dominates only on individual requests, not on fleet CPU budgets.

Canonical Cloudflare framing

Any code that has to be run per-request is in the hottest of hot paths.

If a function participates in every request lifecycle, it gets first-class optimization attention, even if the per-request cost is "only" microseconds.

Typical hot-path optimization moves

1. Flame-graph / stack-trace sampling (concepts/stack-trace-sampling-profiling) to find the high-CPU-share helpers.
2. Flip lookup direction if two collections meet at a membership test (patterns/flip-lookup-direction).
3. Change the data structure — trie over hashmap on miss-heavy short keys, flat sorted Vec over BTreeMap at small N, etc.
4. Custom crate when off-the-shelf options don't match the workload shape (patterns/custom-data-structure-for-hot-path).

Front-end hot path (GitHub, 2026)

The "code that runs on every request" framing generalizes to UI: code that runs on every interaction / every frame / every rendered item is the front-end hot path. GitHub's PR Files-changed tab rewrite is the canonical wiki instance at the web-UI substrate:

• At 10,000+ diff-lines per PR, the diff-line render is the hot path: it runs for every line on every render.
• v1's 5-6 event handlers × 8-13 components per diff line = 20+ handlers per line compounds across the list — 200,000+ handlers per PR.
• v1 → v2 attacks the hot path via patterns/component-tree-simplification (fewer components per line), patterns/single-top-level-event-handler (one handler total, not per-item), patterns/constant-time-state-map (O(1) state lookups per render), and patterns/conditional-child-state-scoping (expensive state only lives where it's active).
• Result: 74 % fewer React components rendered, 78 % INP improvement (concepts/interaction-to-next-paint).

Seen in

• sources/2024-09-10-cloudflare-a-good-day-to-trie-hard — Cloudflare's clear_internal_headers at 1.71 % of 40,000-core fleet CPU; canonical per-request-hot-path instance.
• sources/2026-04-03-github-the-uphill-climb-of-making-diff-lines-performant — GitHub's per-diff-line render as the PR-UI hot path; 10,000+ lines × 20+ event handlers per line pre-optimization; React- runtime-layer cost dominated the DOM-layer cost in the fix.
• sources/2025-10-14-cloudflare-unpacking-cloudflare-workers-cpu-performance-benchmarks — Cloudflare Workers' OpenNext / Next.js / React stack has GC at 10-25 % of request processing time on the 2025-10 benchmark — a tall per-request allocation cost driven by Buffer churn, pipeThrough() allocations, value-oriented ReadableStreams, and JSON.parse(reviver) — all running on every server-rendered request. Same discipline (flame graph → microbench → production re-measure) as the 2024-09-10 Pingora case, applied to a V8-isolate substrate.
• sources/2026-02-27-cloudflare-a-better-streams-api-is-possible-for-javascript — streaming-SSR hot path generalized: per-request GC in Web streams pipelines measured at up to 50 %+ of request CPU, attributed to promise allocation + short-lived { value, done } result objects + pipeThrough() internal buffering. Cloudflare Workers fix to an internal data pipeline reduced JS promises created by up to 200×.

Related

• concepts/stack-trace-sampling-profiling — how you identify the hot path functions worth touching.
• patterns/measurement-driven-micro-optimization — the discipline.
• concepts/tail-latency-at-scale — why hot path CPU time matters for p99s even when the mean looks fine.
• concepts/cache-locality — the dominant optimization lever on modern hardware at µs scales.