CONCEPT Cited by 6 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/flamegraph-profiling) to find the high-CPU-share helpers.
2. Flip lookup direction if two collections meet at a membership test (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 component-tree-simplification (fewer components per line), single-top-level-event-handler (one handler total, not per-item), constant-time-state-map (O(1) state lookups per render), and conditional-child-state-scoping (expensive state only lives where it's active).
• Result: 74 % fewer React components rendered, 78 % INP improvement (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-10-01-cloudflare-introducing-clef-our-open-source-decision-models-and-new-rl — a decision model placed in the agent hot path. Because Clef runs on Workers AI edge GPUs, its latency (median 209 ms; Clef-flash 38.8 ms) is low enough that Cloudflare puts it "into the hot path for agents to make decisions" — then "combine that with one of our LLMs on Workers AI to take action." A new hot-path shape: not a per-request string optimization but a per-decision edge classifier that gates the expensive general-LLM call (patterns/cheap-approximator-with-expensive-fallback).
• sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver — hot-path config reads as a product category. Cloudflare's Workers KV Instant (powered by Quicksilver) is explicitly built for "reading data in the hot path of your applications, especially flags and settings that should be available globally nearly instantly after they've been written" — read on every request, at any scale, at 1.62 ms p99. The worked example is a feature flag read on every request and flipped at a keynote moment. The hot-path requirement (every-request read) is precisely what made classic KV's eventual-consistency TTL unacceptable and justified a separate engine.
• 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/flamegraph-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.

Merged aliases

• zero-allocation-hot-path- hotspot