What optimizing compilers do

Same meaning, less work

A JavaScript engine first runs your code with an interpreter, which starts quickly but runs slowly. When a function runs very often, the engine calls it hot. It then hands the hot function to an optimizing compiler: the part of the engine that builds much faster machine code for it.

The compiler has one firm rule. The fast code must act exactly like your code. It must print the same things, throw the same errors, change the same values, and return the same answers. It only does fewer steps inside the engine.

Each pass in this lesson has a before snippet and an after snippet. Both are plain JavaScript, so you can run them and see that the output stays the same. The after snippet is only a picture of the idea. It is not what a real compiler prints, such as TurboFan or Maglev in V8 (the engine in Chrome and Node). Real engines never change your file; they change only their own IR.

The table lists the six passes. Read each row from left to right: the pass, what it changes, and why that helps.

The Optimizing compilers lesson shows how a whole compiler is built. The Speculation & deoptimization lesson covers guards, and how the engine goes back to slower code when a guess turns out wrong. This lesson stays on the rewrites themselves.

Function inlining: copy a small helper into the loop

A helper is a small function that other code calls. Each call costs a little work: the engine must jump into the function and then come back. Inlining means the compiler copies the helper's body into the code that calls it, so there is no call any more. The compiler only does this when the call always goes to the same small function. Your program still acts as if the 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, which adds 7 to a price. Line 8 calls fee once for each item. The output is 81, because 17 + 27 + 37 is 81. If line 8 runs very often, and it always calls the same small fee, the compiler may inline 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 holds item + 7, the body of fee, right inside the loop. Line 9 prints the same 81. With the body in plain view, the compiler can run more passes on it, such as working out fixed math or picking a cheaper way to store the numbers.

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

Making an object costs work. The engine must find memory for it, and later clean that memory up. Some objects are used only inside one function and then forgotten. Two passes work together on that case:

• Escape analysis checks whether an object escapes, which means whether any code outside the function could ever get hold of it. An object escapes if it is returned, saved in an outside variable, or passed to another function.
• Scalar replacement runs when the object does not escape. It keeps each property as a separate plain value, called a scalar, and skips making 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 makes a point object with x and y. Line 3 reads point.x and point.y and returns a number. The point is never returned, saved outside, passed to other code, or compared with another object. So it does not escape. Line 6 prints 23, because 4 * 2 + 5 * 3 is 23.

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. Lines 2 and 3 hold point_x and point_y, one plain value for each property. Your code still makes an object. The fast code can skip it, because no other code could ever tell the difference.

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

Two more passes often work as a pair:

• Constant folding works out math whose answer never changes, once, while compiling. A constant is a value that never changes.
• Dead-code elimination (DCE for short) removes dead code: code that can never run, or whose result nobody ever uses.

Folding can show that an if test is always false. Then DCE can remove that whole branch.

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 sets DEBUG to false, so the if on line 6 never runs. 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));

Line 1 now holds the ready answer, 3600. The if branch is gone, and DEBUG is gone with it, because nothing reads it any more. Line 8 prints the same 3630.

Loop-invariant code motion: move repeated work out

A loop runs the same lines many times. Some work inside a loop gives the same answer in every round. That work is called loop-invariant; invariant means "does not change". Loop-invariant code motion (LICM for short) moves that work before the loop, so it runs only once. Moving code up like this is also called hoisting. The compiler only does it when the move can't change what the program does.

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));

Math.sqrt works out a square root: Math.sqrt(9) is 3. Line 4 works out Math.sqrt(rate) in every round. item changes each round, but rate does not. With items [9, 16] and a rate of 9, line 9 prints 75, because 9 * 3 + 16 * 3 is 75.

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 works out the square root once and saves it in scale. Line 5 uses scale in each round, and line 10 prints the same 75.

For this array of numbers, the move is safe. A real compiler must also check a few things first:

• Math.sqrt is still the built-in function, not one your code put in its place.
• Turning rate into a number can't run any of your own code.
• rate really stays the same during the loop.

If any of these stops being true, the compiler must not move the work.

Bounds-check elimination: prove the index is safe

When you read values[i], the engine first checks that i is inside the array: not below 0, and below values.length. This is a bounds check; the bounds are the first and last valid positions. Bounds-check elimination removes this check when the compiler can prove that i is always inside the array.

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]));

You never write line 4 in real JavaScript. It only shows the check that the engine does for you. The loop on line 3 already makes sure that i starts at 0 and stops before values.length. So in this loop, the check on line 4 can never fail.

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, because 3 + 4 + 5 is 12. The fast code still keeps guards. If the array or its length changes in a way the proof didn't expect, the engine keeps the checks, or goes back to slower code. Going back like that is called deoptimization.

Representation selection: Smis, doubles, and words

JavaScript has one number type for whole numbers and fractions alike. Inside, the engine can store a number in different ways. Each way is called a representation. When guards prove it is safe, the compiler picks the cheapest one:

• A Smi (small integer) is a whole number small enough to fit right inside the value itself, with no extra memory. An integer is a whole number.
• A double is a 64-bit number that can hold fractions, like 1.5.
• A word32 is a 32-bit whole number. The computer's chip can work with these very fast.

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. The | is the bitwise OR operator. Like every bitwise operator, it first turns its numbers into 32-bit whole numbers, which drops any fraction. OR with 0 then leaves that whole number as it is. So line 9 prints 42.

Line 6 keeps the fraction: line 10 prints 2, because 1.5 + 0.5 is 2. The compiler can also pick a word32 by itself, with no | 0 in your code, when its guards prove the result stays the same.

Each row below is one way the engine can store a number. None of them is a JavaScript type: your code only ever sees numbers.

The next code only runs in Node, with a special setting. %IsSmi is a V8 helper that answers "is this value stored as a Smi?". Helpers that start with % only work when Node starts with --allow-natives-syntax, so this block has no Run button. The ** operator means "to the power of".

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^30 - 1 is Smi", %IsSmi(2 ** 30 - 1));5console.log("2^30 is Smi", %IsSmi(2 ** 30));6console.log("2^31 - 1 is Smi", %IsSmi(2 ** 31 - 1));7console.log("2^31 is Smi", %IsSmi(2 ** 31));8console.log("1.5 is Smi", %IsSmi(1.5));9console.log("(3.9 | 0)", 3.9 | 0);

The Tagged values, Smis & heap numbers lesson shows how values are stored in memory. Here you only need one idea: the compiler can pick a cheaper way to store a number when its guards prove the result stays the same.

Experiment: step through a tiny optimizer

Now put three passes together. The next replay uses a short list of steps written for this lesson, a bit like a tiny IR. It is not V8's real IR. It runs three passes in order: constant folding, then dead-code elimination, then loop-invariant code motion. Watch the list change while the program's answer stays 3675.

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));

Next, try the free version. Turn one pass off at a time and watch what changes:

• Constant folding changes 60 * 60 into 3600.
• Dead-code elimination removes the if (DEBUG) step, so the list gets one step shorter.
• Loop-invariant code motion moves the square root before the loop.
• The program output stays 3675 every time.

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

Speed numbers change from run to run and from computer to computer, so this lesson never claims a speedup. Instead, the lesson's tests start separate Node programs and check facts that stay the same:

• the Node version starts with v22. and the V8 version starts with 12.4.;
• the optimization flags exist (a flag is a setting you give Node when you start it, like --trace-opt);
• a function really gets optimized;
• the trace output mentions TurboFan, V8's optimizing compiler, and inlining;
• turning some passes off does not change the function's result.

Before each run, the tests also clear the test runner's own NODE_TEST_* settings, so each Node program starts clean.

The next code also needs --allow-natives-syntax, so it has no Run button. Line 13 tells V8 to get ready to optimize hotTotal. Line 14 runs it 20 times to warm it up. Line 15 asks V8 to optimize it on the next call. Line 16 prints the result, 45. Line 17 prints a status number. V8 packs several yes-or-no facts about the function into that number, such as whether it is optimized.

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

Don't write code aimed at one pass. These passes explain why simple, steady hot code is easier for engines to speed up. But clear code and real measurements come first.

• Write clear functions first. Don't copy helper bodies into loops by hand.
• In hot code you have measured, pass the same kinds of values, and objects with the same properties, when that fits your data.
• Keep short-lived objects when they make code easier to read. Change them only if a profile shows that making objects is slow.
• Warm up a benchmark with realistic values first, and use its results so the engine can't skip the work.
• Use V8 flags and % helpers only in local checks and tests, never in app code.
• Measure before and after any change you make for speed.

Suppose a profile (a report from a tool like Chrome DevTools that shows where the time goes) points at a slow loop. This lesson gives you ideas to test. Maybe one call reaches different functions. Maybe a short-lived object escapes. Maybe the loop repeats the same work. Maybe the numbers are mixed, so the compiler can't pick a cheap way to store them. Test each idea with a measurement. Don't change code on a hunch.

Common misconceptions

• "The after snippets are what V8 prints." They are pictures of rewrites a compiler might make. They are not real compiler output.
• "Inlining always makes code faster." It makes the fast code bigger, the engine limits how much it inlines, and it can lead to more deoptimizations.
• "If the compiler skips making an object, the object never existed." Your program still acts exactly as if the object was made.
• "Bounds-check elimination makes JavaScript arrays unsafe." It only removes extra checks that can never fail, and only where the compiler has proved that.
• "Smi is a JavaScript type." It is one way the engine stores a number. Your program still sees an ordinary number.

Each row in the table is an idea that is easy to mix up with another. Read what it means, then what it is not.

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 list feels slow when filtering 5,000 items.
// Before you change any helpers by hand, your next step is: ____

Quiz: check your understanding

For each question, first work out what the JavaScript prints. Then name the rewrite that keeps that output.

Key takeaways

• An optimizing compiler rewrites its own IR, never your file, and the fast code must act exactly like your code.
• Inlining copies a small helper into the code that calls it, which lets other passes see more.
• Escape analysis finds objects that never leave a function; scalar replacement then keeps their properties as plain values.
• Constant folding, dead-code elimination, loop-invariant code motion, and bounds-check elimination remove or move work only when the compiler can prove it is safe.
• The compiler can store a number as a Smi, a double, or a word32; your code still only sees ordinary numbers.

Up next: On-stack replacement. It shows how a long loop can switch to fast code while it is still running, without waiting for the next call.