Real-world wins

Case 1 — JSON ingest gone megamorphic

Symptom: a JSON ingest endpoint’s p99 CPU jumped ~30× after a refactor, with no change in request volume. How you saw it: node --cpu-prof showed time dominated by the generic property-load stub, not GC or I/O; --trace-ic reported the result-builder’s downstream access site as MEGAMORPHIC with dozens of distinct maps. Mechanism: the refactor built each result object by iterating input keys (for (const k of Object.keys(input)) out[k] = ...). Input JSON arrives with keys in arbitrary order, so each request walked a different hidden-class transition path, producing a fresh shape almost every time. (This is exactly the hidden-class divergence the track warned about.) Fix: construct from a fixed schema, not input order — out = { id: input.id, name: input.name ?? null, ... } with all keys in a constant order; for genuinely dynamic key sets, store in a Map. Result: the access site returned to monomorphic, p99 dropped back to baseline.

Case 2 — numeric pipeline boxed into HeapNumbers

Symptom: a metrics aggregation pass was 5× slower than a back-of-envelope estimate, with high GC time. How you saw it: the --prof report showed heavy allocation and GC; %DebugPrint on the working array showed PACKED_DOUBLE_ELEMENTS and the accumulators were boxed HeapNumbers. Mechanism: values crossed the Smi range and the pipeline stored intermediate numbers in plain arrays/objects, so every value became a heap-allocated HeapNumber — one allocation and one dereference per number, plus GC pressure. Fix: move the hot numeric buffers to a Float64Array (and keep integer ids Smi-bounded). Typed arrays bypass element-kind tracking and store raw doubles inline — no boxing, no per-element allocation. Result: a large speedup and GC time near zero in the timed region.

Case 3 — GC pauses from per-request allocation churn

Symptom: periodic latency spikes correlated with GC events; throughput fine on average, p99 ugly. How you saw it: the DevTools Performance panel (or --prof) attributed the spikes to GC, and the heap timeline showed sawtooth growth — a new burst of short-lived objects allocated per request. Mechanism: the handler allocated many temporary objects per request, filling the young generation and triggering frequent minor GCs (and occasional major ones). (See garbage collection for the generational cost model.) Fix: reduce allocations in the hot path — reuse buffers/objects (a small pool), hoist invariant allocations out of the per-request loop, and avoid creating closures per call. Result: fewer, shorter GC pauses; the p99 spikes flattened.

Case 4 — a deopt loop from polymorphic arguments

Symptom: a hot function was fast, then slow on a cadence — the fast-then-slow signature. How you saw it: --trace-opt --trace-deopt filtered to the function showed it optimised, then an eager deoptimizing ... reason: wrong map at the same offset, then re-optimised — repeating. Mechanism: the function received objects of several shapes (a polymorphic argument), so TurboFan’s speculation broke every time an unexpected shape arrived, triggering a deopt loop. Fix: monomorphise the input — normalise all callers to one shape before the hot function, or split into shape-specific variants. Result: the deopt loop stopped; the function stayed in optimised code.

Case 5 — microtask starvation stalling a render

Symptom: the UI froze for hundreds of milliseconds even though no single function was slow. How you saw it: the Performance panel showed one long task with a huge microtask queue draining before the next render; no paint occurred until it emptied. Mechanism: a recursive promise chain kept enqueuing microtasks, and because the microtask queue is drained exhaustively before the loop yields, rendering and input were starved. (See microtasks vs macrotasks.) Fix: break the work across macrotasks — yield with setTimeout(…, 0) / scheduler.postTask (or await a macrotask) between chunks so the event loop can render and process input. Result: the UI stayed responsive; work completed in chunks between frames.

The decision framework

Notice the discipline behind all five: never start from a guess. Profile first to find the single dominant cost — fixing the second-biggest cost while the biggest dominates is wasted work. Name the mechanism with a trace flag or %DebugPrint so the fix targets the actual cause, not a symptom. Fix the data or control flow — a stable shape, a typed array, fewer allocations, monomorphic inputs, a yield point — because the cause is almost never in the engine. Then verify with a guarded benchmark (an honest harness from the last lesson), and keep a regression gate in CI so the win does not silently erode in the next refactor.