Thin Link-Time Optimization in the Chromium Browser

This article explores Thin Link-Time Optimization (ThinLTO), a scalable compiler technology that enhances software performance without the massive memory and time overhead of traditional link-time optimization. It breaks down the fundamental mechanics of ThinLTO, explains how it achieves parallelized cross-module optimizations, and details the specific ways it transforms the linking process of the Chromium web browser to produce a faster, smaller, and more efficient final binary.

Understanding Traditional LTO vs. ThinLTO

During a standard C++ build process, a compiler translates individual source files into object files independently. Because the compiler only sees one file (translation unit) at a time, it misses optimization opportunities that cross file boundaries.

Traditional Link-Time Optimization (LTO) solves this by delaying code generation. Instead of outputting machine code, the compiler outputs Intermediate Representation (IR) bitcode. At the linking stage, the linker merges all IR files into one massive module, allowing the compiler to optimize the entire program as a single unit. However, for massive codebases, this monolithic approach requires tens of gigabytes of RAM and hours of single-threaded processing time.

ThinLTO, implemented in the LLVM/Clang toolchain, achieves the performance benefits of monolithic LTO while remaining fast and memory-efficient. Instead of merging all IR files into one giant module, ThinLTO operates in three distinct phases:

  1. Compile Phase: The compiler outputs IR bitcode alongside a compact summary index of the functions and symbols within that specific file.
  2. Thin Link Phase: The linker reads only the lightweight summaries—not the actual code—and combines them into a global index. It uses this index to map out which functions in one file would benefit from being imported into another. This step takes only seconds and uses minimal memory.
  3. Backend Phase: The compiler launches multiple parallel threads. Each thread takes an original IR file, uses the global index to import only the relevant code from other files, performs optimizations, and generates the final machine code.

How ThinLTO Optimizes the Chromium Binary

Chromium consists of tens of millions of lines of C++ code. Monolithic LTO is entirely impractical at this scale, making ThinLTO essential for building official Chrome releases. When linking Chromium, ThinLTO optimizes binary performance through several key mechanisms.

Cross-Module Function Inlining

Function inlining is the single most impactful optimization enabled by ThinLTO. In C++, calling a function carries overhead (pushing registers, jumping to a new memory address, and returning). If a function in FileA.cc calls a small helper function defined in FileB.cc, a standard compiler cannot inline it because it cannot see inside FileB.cc.

During the Thin Link phase of Chromium's build, the global index identifies frequently called small functions across different modules. In the backend phase, ThinLTO imports those specific functions into the calling module and replaces the function call directly with the function's body. This eliminates call overhead and exposes further optimization opportunities to the compiler.

Global Dead Code Elimination

Because Chromium integrates numerous massive third-party libraries (such as Skia, V8, and WebRTC), many compiled functions and data structures end up unused in the final browser configuration. Using the global summary index, ThinLTO constructs a complete reference graph of the entire browser. If it detects functions or global variables that are never referenced across any module, it strips them out completely. This reduces the final binary size, which improves instruction cache locality and reduces the browser's memory footprint.

Devirtualization and Constant Propagation

Chromium's architecture relies heavily on object-oriented programming and virtual functions, which require indirect memory lookups (vtable lookups) at runtime. ThinLTO gives the compiler a broader view of class hierarchies across different files. When it can prove that a virtual function call only ever resolves to a single implementation, it "devirtualizes" the call, turning a slow indirect lookup into a fast direct call—which can then be inlined.

Similarly, ThinLTO performs interprocedural constant propagation. If a constant value is passed as an argument to a function in another file, ThinLTO propagates that constant across the file boundary, allowing the compiler to simplify math, remove dead branches (if/else statements where the condition is now known at compile time), and generate tighter machine code.

Build Scalability and Incremental Caching

Beyond runtime binary performance, ThinLTO optimizes the linking process itself. Because the backend phase operates on individual modules independently using the read-only global index, the workload is distributed across all available CPU cores.

Furthermore, ThinLTO supports incremental builds. If a Chromium developer modifies a single .cc file, the Thin Link phase updates the global index, and the backend only recompiles the modules whose import lists were directly affected by that specific change. All other modules pull their compiled machine code directly from a local cache.

The Final Impact on Chromium

By deploying ThinLTO alongside the LLD linker, the Chromium project achieves a 5% to 10% improvement in execution speed across standard browser benchmarks compared to non-LTO builds. It delivers these runtime speedups and binary size reductions while keeping memory usage low enough to run on standard developer workstations and automated continuous integration servers.