What optimizing compilers do

Same meaning, less work

The optimizing compiler sits after the interpreter, type feedback, inline caches, and speculative guards. Its job is not to invent a different JavaScript language. Its job is to prove that a hot piece of code can do fewer internal operations while printing, throwing, mutating, and returning exactly the same observable results.

The before and after snippets in this lesson are source-level pictures of what can happen to optimized IR. They are deliberately written as JavaScript so you can run them and confirm the output stays the same. They are not real TurboFan, Maglev, Ion, or JavaScriptCore output.

The neighbouring Optimizing compilers lesson covers compiler pipelines, IRs, SSA, and engine architecture. The previous Speculation & deoptimization lesson covers guards and bailouts. Here we stay focused on the transformations themselves.

Function inlining: bring the tiny helper into the hot caller

Inlining means replacing a call in optimized IR with the body of the called function. It is useful only when the compiler has evidence that the call target is stable enough and the body is worth copying. The later code still behaves as if the function call happened.

1function fee(price) {2  return price + 7;3}4 5function totalWithHelper(items) {6  let total = 0;7  for (const item of items) {8    total += fee(item);9  }10  return total;11}12 13console.log(totalWithHelper([10, 20, 30]));

Line 1 defines fee. Line 8 calls it for every item. The output is 81: 17 + 27 + 37. If this call site is hot and feedback says it keeps calling the same small helper, the optimizer can consider inlining it.

1function totalWithInlinedHelper(items) {2  let total = 0;3  for (const item of items) {4    total += item + 7;5  }6  return total;7}8 9console.log(totalWithInlinedHelper([10, 20, 30]));

Line 4 is the teaching picture: item + 7 is the helper body. In real optimized IR, that exposed expression may let later passes fold constants, choose integer operations, or remove checks around the caller.

1function fee(price) {2  return price + 7;3}4 5function totalWithHelper(items) {6  let total = 0;Run7  for (const item of items) {8    total += fee(item);9  }10  return total;11}12 13console.log(totalWithHelper([10, 20, 30]));

Escape analysis and scalar replacement

Escape analysis asks whether an object's identity can be observed outside the optimized region. If the object never escapes, scalar replacement can represent its fields as separate local values instead of allocating the object.

1function routeFee(x, y) {2  const point = { x, y };3  return point.x * 2 + point.y * 3;4}5 6console.log(routeFee(4, 5));

Line 2 creates a point. Line 3 reads point.x and point.y, then returns a number. The point is not returned, stored globally, passed to unknown code, or compared by identity.

1function routeFeeScalarPicture(x, y) {2  const point_x = x;3  const point_y = y;4  return point_x * 2 + point_y * 3;5}6 7console.log(routeFeeScalarPicture(4, 5));

The after picture prints the same 23. It shows the idea: the object's fields can live as two scalar values in optimized code. The source still says an object exists; the optimized representation can be cheaper because no outside code can tell.

1function routeFee(x, y) {2  const point = { x, y };3  return point.x * 2 + point.y * 3;4}5 6console.log(routeFee(4, 5));Run

Constant folding and dead-code elimination

Constant folding computes fixed expressions while compiling. Dead-code elimination removes operations whose results cannot be observed. These two often work together: folding can prove that a branch is never taken, and DCE can remove it.

1const DEBUG = false;2const SECONDS_PER_HOUR = 60 * 60;3 4function expiry(seconds) {5  const total = seconds + SECONDS_PER_HOUR;6  if (DEBUG) {7    console.log("debug", total);8  }9  return total;10}11 12console.log(expiry(30));

Line 2 is always 3600. Line 1 makes the branch on line 6 unreachable in this snippet. The program prints only 3630; it never prints debug.

1const SECONDS_PER_HOUR = 3600;2 3function expiryFoldedPicture(seconds) {4  const total = seconds + SECONDS_PER_HOUR;5  return total;6}7 8console.log(expiryFoldedPicture(30));

Loop-invariant code motion: move repeated work out

A value is loop-invariant when it does not change from one iteration to the next. If moving it earlier does not change observable behavior, the compiler can compute it once before the loop.

1function scaledTotal(items, rate) {2  let total = 0;3  for (const item of items) {4    total += item * Math.sqrt(rate);5  }6  return total;7}8 9console.log(scaledTotal([9, 16], 9));

Line 4 repeats Math.sqrt(rate). The array item changes each iteration, but rate does not. The function prints 75 for [9, 16] and rate 9.

1function scaledTotalHoistedPicture(items, rate) {2  const scale = Math.sqrt(rate);3  let total = 0;4  for (const item of items) {5    total += item * scale;6  }7  return total;8}9 10console.log(scaledTotalHoistedPicture([9, 16], 9));

Line 2 computes the square root once. Line 5 reuses scale. This move is safe here because Math.sqrt with a number argument has no user-defined callback, and rate is not changed by the loop.

Bounds-check elimination: prove the index is safe

Array element access needs safety checks inside the engine. Bounds-check elimination removes redundant checks when the optimizer proves the index stays within the array length for the optimized path.

1function sumWithModelledBoundsChecks(values) {2  let total = 0;3  for (let i = 0; i < values.length; i += 1) {4    if (i < 0 || i >= values.length) throw new RangeError("out of bounds");5    total += values[i];6  }7  return total;8}9 10console.log(sumWithModelledBoundsChecks([3, 4, 5]));

Real JavaScript does not require you to write line 4. It is a teaching model for the internal safety check. The loop header on line 3 already says i starts at zero and stops before values.length, so the check is redundant for this path.

1function sumAfterBoundsCheckElimination(values) {2  let total = 0;3  for (let i = 0; i < values.length; i += 1) {4    total += values[i];5  }6  return total;7}8 9console.log(sumAfterBoundsCheckElimination([3, 4, 5]));

Both snippets print 12. Optimized code still needs guards: if the array shape changes, the length changes unexpectedly, or the path no longer matches the proof, the engine must keep checks or deoptimize.

Representation selection: Smis, doubles, and words

JavaScript has one number type for both integers and fractions. Engines use internal representations to make proven cases cheaper. A Smi is a small integer stored directly in a tagged value. A double is a 64-bit floating-point number. A word32 operation uses 32-bit integer machine semantics.

1function addWord32(x) {2  return (x + 1) | 0;3}4 5function addNumber(x) {6  return x + 0.5;7}8 9console.log(addWord32(41));10console.log(addNumber(1.5));

Line 2 uses | 0, which is real JavaScript syntax that converts through signed 32-bit integer semantics. Line 6 keeps fractional number behavior. Optimizers can also choose representations internally without source | 0 when guards prove it is safe.

1console.log("node", process.version.replace(/\.\d+$/, ".x"));2console.log("v8", process.versions.v8.split(".").slice(0, 2).join("."));3console.log("pointer compression", process.config.variables.v8_enable_pointer_compression);4console.log("2^31 - 1 is Smi", %IsSmi(2 ** 31 - 1));5console.log("2^31 is Smi", %IsSmi(2 ** 31));6console.log("1.5 is Smi", %IsSmi(1.5));7console.log("(3.9 | 0)", 3.9 | 0);

The neighbouring Tagged values, Smis & heap numbers lesson goes deeper on how values live in memory. Here you only need the optimization idea: a compiler can pick a cheaper representation when feedback and guards prove that representation preserves behavior.

Experiment: step through a tiny optimizer

Now combine three passes. The next replay uses a tiny three-address-style IR written for this lesson. It is not V8 IR, but it applies real optimization ideas to a real computed result: the output stays 3675 while the operation list changes.

1const ops = [Run2  "const SECONDS = 60 * 60",3  "const DEBUG = false",4  "let total = 0",5  "loop: const scale = Math.sqrt(rate)",6  "loop: const price = items[i] * scale",7  "loop: total = total + price",8  "if (DEBUG) console.log(total)",9  "return total + SECONDS",10];11 12const folded = foldConstants(ops);13const cleaned = removeDeadBranches(folded);14const hoisted = hoistLoopInvariantWork(cleaned);15console.log(render(hoisted));

Try the free-play version next. Turn one pass off at a time. Constant folding changes an operation, DCE removes one, and LICM changes where the square root happens. The result should stay fixed.

1const passes = new Set(["fold", "dce", "licm"]);2const result = optimizeTinyIR(passes);3 4console.log(result.operations.join("\n"));5console.log("operation count", result.opCount);6console.log("program output", result.output);

Real Node and V8 evidence without timing claims

The tests for this lesson run child Node processes. They strip NODE_TEST_* environment variables, assert version patterns instead of exact patch numbers, and check stable facts: flags exist, optimization status is nonzero, trace output mentions TurboFan and inlining, and disabling selected TurboFan passes does not change the function's result.

1function helper(x) {2  return x + 7;3}4 5function hotTotal(n) {6  let total = 0;7  for (let i = 0; i < n; i += 1) {8    total += helper(i);9  }10  return total;11}12 13%PrepareFunctionForOptimization(hotTotal);14for (let round = 0; round < 20; round += 1) hotTotal(20);15%OptimizeFunctionOnNextCall(hotTotal);16console.log("result", hotTotal(5));17console.log("status", %GetOptimizationStatus(hotTotal));

Use this knowledge safely

Working developers should not write code for a single pass name. These optimizations explain why stable, simple hot paths are easier for engines to optimize, but readability and measurements come first.

• Write clear functions first; do not manually inline everything.
• Keep measured hot paths reasonably type-stable and shape-stable when it fits the data model.
• Let temporary objects stay readable unless profiling points at allocation pressure.
• Warm benchmarks with representative values and keep results used.
• Use V8 native syntax and flags only in local diagnostics or tests.
• Measure before and after any performance-motivated rewrite.

If a profile points to a hot loop, this lesson gives you vocabulary for hypotheses: maybe a call target is unstable, a temporary object escapes, the loop repeats invariant work, or mixed numeric representations keep the path generic. Test the hypothesis; do not optimize by superstition.

Common misconceptions

• “The after snippets are what V8 prints.” They are teaching pictures of possible IR rewrites, not real compiler output.
• “Inlining always makes code faster.” It has code-size, stack-trace, budget, and deoptimization trade-offs.
• “A removed allocation means the object never existed semantically.” JavaScript behavior still matches the source object.
• “Bounds-check elimination removes safety from JavaScript arrays.” It removes redundant internal checks only on proven optimized paths.
• “Smi is a JavaScript type.” It is an engine representation. Your program still sees numbers.

Practice exercises

function fee(price) { return price + 7; }
function total(items) { return items.reduce((sum, item) => sum + fee(item), 0); }
console.log(total([10, 20, 30]));

function routeFee(x, y) {
  const point = { x, y };
  return point.x * 2 + point.y * 3;
}
console.log(routeFee(4, 5));

for (const item of items) {
  total += item * Math.sqrt(rate);
}

console.log(3.9 | 0);

// A product grid feels slow when filtering 5,000 items.
// Before rewriting helpers by hand, your next step is: ____

Quiz: check your understanding

Answer by preserving JavaScript output first, then naming the internal rewrite.

Key takeaways

• Optimizing compilers rewrite internal IR, not your source file, and must preserve observable JavaScript behavior.
• Inlining exposes a stable callee body to the caller, which can unlock more optimizations.
• Escape analysis can prove a temporary object never escapes, letting scalar replacement remove the allocation internally.
• Constant folding, DCE, LICM, and bounds-check elimination remove or move work only when proofs and guards make it safe.
• Representation selection chooses Smis, doubles, or word operations internally; JavaScript still exposes normal values.

Up next: On-stack replacement, where a long-running loop can enter optimized code without waiting for the next function call.