Why Chromium Added Sparkplug Between Ignition and TurboFan

The Chromium web browser introduced the Sparkplug non-optimizing baseline compiler into its V8 JavaScript engine to bridge the significant performance gap between the fast-starting Ignition interpreter and the resource-heavy TurboFan optimizing compiler. By rapidly translating existing bytecode directly into machine code without waiting for complex profiling data, Sparkplug delivers an immediate execution speed boost while reducing CPU overhead. This article explains the limitations of the previous two-tier V8 architecture, how Sparkplug functions as a middle tier, and why its introduction resulted in a major leap forward for real-world web browsing performance.

The Limitations of the Two-Tier Architecture

Before Sparkplug was introduced in 2021, Chromium’s V8 engine relied on a two-tier execution pipeline consisting of Ignition and TurboFan:

  • Ignition (The Interpreter): Ignition compiles JavaScript into concise bytecode. It starts executing code almost instantly and uses very little memory. However, because it has to interpret bytecode instructions one by one, its execution speed is relatively slow.
  • TurboFan (The Optimizing Compiler): As code runs in Ignition, V8 collects profiling data (type feedback) on how the code is being used. Once a function becomes "hot" (runs frequently), TurboFan uses this data to compile the bytecode into highly optimized machine code.

The problem with this two-tier system was the massive trade-off between startup speed and peak performance. TurboFan generates exceptionally fast code, but the compilation process itself is slow and consumes a lot of CPU power.

During the time it took for Ignition to gather enough type feedback and for TurboFan to finish compiling, the browser was forced to keep running slow bytecode. Furthermore, if TurboFan made an optimization assumption that later proved wrong, it had to "deoptimize" the code and fall all the way back to the slow Ignition interpreter, wasting valuable CPU cycles.

Enter Sparkplug: The Middle Tier

To solve this bottleneck, the V8 team introduced Sparkplug to sit directly between Ignition and TurboFan. Sparkplug is a non-optimizing baseline compiler designed with one primary goal: generate machine code as fast as humanly possible.

Instead of waiting for code to become extremely hot, V8 can now pass functions to Sparkplug very early in their lifecycle. Sparkplug quickly generates machine code that is much faster than Ignition's bytecode interpretation, though not quite as fast as TurboFan's optimized code.

How Sparkplug Achieves Extreme Compilation Speed

Sparkplug is able to compile code almost instantaneously because it takes several architectural shortcuts that traditional compilers cannot:

  • It compiles from bytecode, not source code: Sparkplug does not read raw JavaScript or build an Abstract Syntax Tree (AST). Because Ignition has already done the hard work of parsing the JavaScript into bytecode, Sparkplug simply reads that bytecode and translates it directly into machine code.
  • It performs a single linear pass: Sparkplug does not analyze the code for potential optimizations, nor does it generate an intermediate representation (IR). It walks through the bytecode from start to finish in a single pass, emitting pre-written snippets of machine code for each bytecode instruction.
  • It shares Ignition’s stack frames: Sparkplug maintains the exact same memory layout (stack frames) as the Ignition interpreter. This makes transitioning execution between Ignition, Sparkplug, and TurboFan completely seamless and computationally cheap.

The Benefits to Chromium

Inserting Sparkplug into the V8 pipeline fundamentally improved how Chromium handles modern, JavaScript-heavy websites:

  1. Faster Execution Earlier: Web applications no longer get stuck running slow bytecode while waiting for the optimizing compiler to kick in. Sparkplug provides a massive speed upgrade over Ignition with virtually zero wait time.
  2. Less Pressure on TurboFan: Because Sparkplug executes code at a very respectable speed, V8 does not need to rush code into TurboFan. It can wait longer to ensure the profiling data is completely stable.
  3. Fewer Costly Deoptimizations: Because V8 waits longer to invoke TurboFan, the optimizing compiler makes better decisions based on more accurate data. Furthermore, if TurboFan does have to deoptimize, the code can fall back to fast Sparkplug machine code rather than slow Ignition bytecode.

By filling the gap between interpretation and heavy optimization, Sparkplug reduced the CPU time spent compiling code and improved Chromium's overall real-world browsing performance by 5% to 15% immediately upon its release.