When V8 allocates a Context (and what it costs)

The allocation rule: capture, nothing else

A Context is not allocated because you opened a function or a block. It is allocated only when the compiler determines that a variable in that scope is captured by an inner function — referenced by a nested function or arrow that may outlive the current frame. If no inner function closes over anything, the scope needs no Context at all: its variables live in registers or stack slots and cost nothing beyond the frame.

This is the single most important cost model in this unit. Most functions you write allocate zero Contexts, because they either define no inner functions or define inner functions that capture nothing. The cost appears precisely at capture.

function noCapture(xs) {
  let sum = 0;
  for (let i = 0; i < xs.length; i++) sum += xs[i];
  return sum;            // no inner function -> no Context, all registers
}

function capture(xs) {
  let sum = 0;
  xs.forEach(x => sum += x); // the arrow captures 'sum' -> 'sum' context-allocated
  return sum;                // one Context for this scope
}

The per-iteration trap: let in a loop + capture

let and const declared in a for loop header create a fresh binding per iteration. This is the feature that makes the classic “all my callbacks print the last value” bug go away. But the implementation has a cost when the body captures that binding.

const fns = [];
for (let i = 0; i < n; i++) {
  fns.push(() => i);   // captures THIS iteration's 'i'
}
// Each callback returns its own i: fns[3]() === 3. Correct!
// But: a NEW Context is allocated for each iteration to hold that iteration's i.

For the closures to each see a different i, each iteration’s i must live somewhere distinct — so V8 allocates a fresh Context per iteration and copies the binding in. With n large and the body capturing, that is n heap allocations and n objects for the GC to trace. Contrast var, which has one binding for the whole loop:

const fns = [];
for (var i = 0; i < n; i++) {
  fns.push(() => i);   // all capture the SAME 'i'
}
// Every callback returns the final i (=== n). One binding, one Context.

var allocates at most one Context here (still one, because the binding is captured) — but it does not multiply by n. The widely-repeated advice “always use let” is correct for correctness, but in a genuinely hot loop that creates closures, the per-iteration Context is a real, measurable cost.

What forces a Context, and how to minimise it

Things that force context allocation: any closure over a variable, a with block, a direct eval (it can read/declare locals), and in some cases observing arguments in ways that defeat analysis. The levers to reduce it on hot paths:

• Hoist the closure out of the loop. If the callback does not actually need each iteration’s binding, define it once outside the loop. No per-iteration Context.
• Pass data as arguments instead of capturing. A function that receives x as a parameter does not capture it; parameters are cheaper than a captured Context slot and keep the call shape predictable (next lesson).
• Use an index, not a captured binding, when you only need the value at call time. Sometimes a plain for with var plus an explicit copy is the right tool in a million-iteration hot loop — measure it.
• Keep big or long-lived data out of captured scopes (the retention lesson) — a separate concern from allocation count but the same discipline.

Applied together, these four levers reduce both the number of Context objects the GC must trace and the number of heap allocations per hot iteration. Without hoisting, even a trivial () => i inside a tight loop silently multiplies allocations by n — the kind of cost that only shows up in an allocation profile, not in a code review.

// Hot path: avoid n per-iteration Contexts when capture isn't needed.
function attach(handlers, fn) {            // fn defined ONCE, captures nothing per-iter
  for (let i = 0; i < handlers.length; i++) handlers[i].on(fn);
}