V8 Ignition and TurboFan Pipeline

Why Is the First Call Always Slow?

Run this benchmark and the numbers will make no sense at first:

function add(a, b) { return a + b; }

// First 100 calls: ~0.8ms total
for (let i = 0; i < 100; i++) add(i, i);

// Next 100,000 calls: ~0.3ms total
for (let i = 0; i < 100000; i++) add(i, i);

100,000 calls take less time than the first 100. That makes no sense — unless you understand what V8 is doing behind your back. The first calls run through an interpreter. Once V8 decides the function is "hot," it compiles it to native machine code. After that, it runs at near-C++ speed.

This is the compilation pipeline, and once you understand it, you'll never think about JavaScript performance the same way again.

The Pipeline at 30,000 Feet

Here's the full journey your JavaScript source code takes:

1. Parser reads source text, produces an Abstract Syntax Tree (AST)
2. Ignition (interpreter) walks the AST, generates compact bytecode, starts executing immediately
3. Sparkplug (baseline compiler, V8 9.1+) compiles bytecode to unoptimized machine code with zero analysis — a quick speedup over the interpreter
4. Maglev (mid-tier compiler, V8 11.3+) generates mildly optimized code using type feedback, bridging the gap between Sparkplug and TurboFan
5. TurboFan (optimizing compiler) uses type feedback collected during interpretation to generate highly optimized machine code with speculative optimizations

This is tiered compilation — every tier trades startup speed for peak throughput.

Parsing: Source Text to AST

Here's something most people don't realize: when V8 first encounters a script, it doesn't parse everything immediately. It uses lazy parsing (also called pre-parsing):

function outerFunction() {
  // V8 fully parses this — it's called immediately
  return innerFunction();
}

function innerFunction() {
  // V8 pre-parses this — notes it exists, skips the body
  // Full parse happens only when innerFunction() is actually called
  return "expensive computation";
}

outerFunction(); // Now innerFunction gets fully parsed

Pre-parsing is roughly 2x faster than full parsing. For large codebases, this means V8 only pays the full parsing cost for code that actually executes.

The parser produces an AST. For function add(a, b) { return a + b; }, the AST looks roughly like:

FunctionDeclaration "add"
  Parameters: [a, b]
  Body:
    ReturnStatement
      BinaryExpression (+)
        Left: Variable "a"
        Right: Variable "b"

Ignition: AST to Bytecode

Ignition is V8's interpreter. It walks the AST and generates bytecode -- basically a compact, stack-machine instruction set. For our add function, it looks like this:

LdaNamedProperty a0, [0]   // Load parameter 'a'
Add a1                       // Add parameter 'b' to accumulator
Return                       // Return the accumulator value

Ignition bytecodes are much smaller than machine code (typically 25-50% the size of equivalent x64 instructions), which matters for memory. A large application might have tens of thousands of functions — keeping them all as machine code would consume gigabytes.

But here's the thing most people miss: the critical thing Ignition does beyond execution is collecting type feedback. Every operation records what types it has seen into a data structure called a FeedbackVector. This is the intelligence that TurboFan uses to speculate.

Sparkplug and Maglev: The Middle Tiers

Before TurboFan kicks in, there are two more compilation tiers you should know about:

Sparkplug (V8 9.1+) compiles Ignition bytecode 1:1 into machine code. No optimization, no analysis — it literally walks each bytecode and emits the equivalent native instructions. It runs roughly 2x faster than the interpreter because it eliminates dispatch overhead.

Maglev (V8 11.3+) sits between Sparkplug and TurboFan. It builds a simplified graph from bytecode, uses the type feedback from the FeedbackVector, and applies basic optimizations (common subexpression elimination, register allocation). Maglev compiles 10-20x faster than TurboFan while producing code that's 50-80% as fast.

The tiers work together:

TurboFan: Speculative Optimization

Now we get to the crown jewel. TurboFan takes the type feedback from the FeedbackVector and literally bets on it. If add(a, b) has only ever been called with small integers (SMIs), TurboFan generates machine code that:

1. Checks if both arguments are SMIs (a single bit check)
2. Adds them with a native addl instruction
3. Checks for integer overflow
4. Returns the result

No boxing, no type dispatch, no property lookups. This is why it approaches C++ speed.

// TurboFan sees: add() always receives integers
// It generates something like this pseudocode:

// OPTIMIZED add(a, b):
//   if (!isSmi(a)) goto DEOPTIMIZE
//   if (!isSmi(b)) goto DEOPTIMIZE
//   result = a + b (native integer add)
//   if (overflow) goto DEOPTIMIZE
//   return result
//
// DEOPTIMIZE:
//   restore interpreter state
//   jump back to Ignition

Those DEOPTIMIZE guards are critical. If the speculation is wrong — someone calls add("hello", "world") — V8 bails out of the optimized code and falls back to the interpreter. This is called deoptimization, and it's expensive.

Production Scenario: The 200ms Startup Regression

This is a real one. A team adds a configuration validation function that runs once at startup:

function validateConfig(config) {
  // 500 lines of complex validation logic
  // called exactly once during initialization
}

They notice startup time increases by 200ms. The cause: the function was wrapped as an IIFE (Immediately Invoked Function Expression), which V8 historically treated as a signal for eager compilation — assuming IIFEs are hot and compiling them eagerly. Note: V8's heuristics evolve across versions, and modern V8 may handle this differently. You can verify with --trace-opt and --trace-deopt flags.

// This triggers eager optimization — V8 sees IIFE pattern
(function validateConfig(config) {
  // 500 lines get TurboFan-compiled even though it runs once
})();

// This stays lazy — only Ignition bytecode
function validateConfig(config) {
  // Only compiled by Ignition, fast to start
}
validateConfig(globalConfig);

The fix: unwrap the IIFE. Startup drops by 200ms because Ignition handles the one-time code instantly instead of waiting for TurboFan.

Common Mistakes

Quiz: The Compilation Pipeline

Key Rules

Interactive: V8 Compilation Pipeline