Recent Developments in Linker Performance and Speed

Linkers are an essential part of software build processes, but linking large programs can become a significant bottleneck. In recent years, considerable effort has gone into improving linker speed. This report covers enhancements in traditional linkers, new approaches in modern linkers, innovations like incremental and parallel linking, updates in popular linker tools (GNU ld, Gold, LLVM lld, mold, etc.), real-world benchmarks, and the challenges and future trends in optimizing link time.

Enhancements in Traditional Linker Performance

Early Unix linkers (like the GNU Binutils ld using the BFD backend) were designed with portability and feature support in mind, not speed​

sourceware.org. As software projects grew, the slow link times of these traditional linkers became problematic. This led to new developments and optimizations even in the “traditional” tools:

• GNU ld (BFD) – The classic GNU linker has historically been slow (single-threaded and handling many formats), but recent work has boosted its performance. In fact, as of binutils 2.41 (2023), GNU ld received substantial optimizations and is now noticeably faster – reportedly even outperforming the once-faster GNU Gold in recent versions​

  github.com. It remains feature-rich and portable, but its maintainers have begun to prioritize speed more than before​github.com​sourceware.org.

• GNU Gold – Gold was introduced by Google in 2008 specifically to speed up linking of large C/C++ applications. It delivered up to five times faster link times compared to the older GNU ld at the time​

  lwn.netby using more efficient data structures and multi-threading. Gold became a drop-in replacement for ld.bfd and provided an immediate relief for developers spending long times in link cycles​lwn.net. However, Gold has suffered from lack of maintenance in recent years. By 2025 it has been deprecated in GNU Binutils (removed from default releases) due to waning support​lwn.net. Many Linux distributions stuck with ld.bfd as default, and now with ld’s recent speedups and Gold’s deprecation, the focus has shifted back to improving ld.bfd or adopting newer linkers.

• Microsoft’s LINK (COFF linker) – On Windows, the MSVC toolchain’s linker has traditionally mitigated slow link times with incremental linking (the /INCREMENTAL option) enabled by default for debug builds​

  news.ycombinator.com​learn.microsoft.com. This allows the linker to update an existing .exe/.dll by patching only changed parts, avoiding a full relink on every build. This was a notable early approach to speed up linking in development cycles. Over time, Microsoft’s linker has also seen performance improvements; recent reports suggest that its speed has improved, narrowing the gap between MSVC’s linker and faster alternatives like lld on Windows​users.rust-lang.org.

In summary, traditional linkers have seen incremental performance gains – GNU ld through targeted optimizations in new releases, and Gold providing a faster alternative for a period. Yet, to handle modern software sizes, completely new linking approaches have also emerged.

Modern Approaches for Faster Linking in Compilers

Modern compiler toolchains have introduced new linker implementations built from the ground up for speed. Two prominent examples are LLVM lld and mold, which dramatically outperform older linkers:

• LLVM lld – The LLVM project’s linker (lld) was designed to be a fast, drop-in replacement for Unix linkers. It has been adopted in many scenarios (Clang, Rust, etc.) as an alternative to GNU ld. In benchmarks, LLD has shown impressive gains: it can be 2–3× faster than GNU Gold and about 5–10× faster than GNU ld.bfd on large programs​

  phoronix.com. This “lightning fast” performance comes from several design choices:

  • Multi-threaded design – LLD efficiently uses multiple cores by parallelizing work like symbol resolution and I/O, unlike ld.bfd which is single-threaded​phoronix.com.
  • Efficient data structures – It uses optimized algorithms and data structures for symbol lookup, section merging, etc., avoiding the bottlenecks present in older linkers​phoronix.com.
  • Custom memory allocation – LLD employs a custom memory allocator tuned for linking workloads to reduce malloc overhead​phoronix.com.
  • Continuous optimization – The LLD developers regularly profile and refine performance-critical paths, meaning each release often brings further speed-ups​phoronix.com.

  These improvements make LLD significantly faster than traditional GNU linkers in practice. For example, one analysis found that linking large applications with LLD was 2–3× faster than Gold and 5–10× faster than ld.bfd under the same conditions​

  phoronix.com. Many compilers (like Clang) allow using LLD via a flag (e.g. -fuse-ld=lld) and projects have reported substantial build-time reductions by switching to LLD.

• mold – First released in 2021, mold is a new open-source linker focused on pushing speed to the limit. Written by the original author of LLD (Rui Ueyama), mold’s goal is to be “several times faster” than LLD, which was previously the fastest open-source linker​

  github.com. Mold aggressively exploits parallelism and modern hardware:

  • It utilizes all available CPU cores throughout the link process​infoq.com, doing work like input file parsing, symbol table building, and relocation in parallel.
  • It uses memory-mapped I/O and other techniques to quickly read huge numbers of object files and write out the output in large bursts, nearing the limits of disk throughput. In fact, mold is so fast that it has been described as being only about 2× slower than simply copying the output file with cp on disk​github.com– meaning most of the remaining overhead is just the time to write the output file itself.
  • Mold’s code employs scalable concurrency-friendly data structures (e.g. concurrent hash maps) and minimizes synchronization, based on lessons learned from LLD’s design.

  The performance results of mold are striking. In one set of benchmarks comparing linkers on large codebases (run on a 16-core / 32-thread machine):

  • MySQL 8.3 (0.47 GB output): GNU ld took ~10.8s, Gold 7.5s, LLD 1.64s, and mold just 0.46s​github.com.
  • Clang 19 (1.56 GB output): ld.bfd ~42s, Gold 33s, LLD 5.2s, mold 1.35s​github.com.
  • Chromium 124 (1.35 GB output): Gold ~27.4s, LLD 6.1s, mold 1.52s​github.com(ld.bfd could not complete this link in a reasonable time).

  In other words, mold often delivers a 3–4× speedup over LLD, which itself was already much faster than older linkers​

  github.com. One case study noted mold can link a large Chrome executable (~2 GB) in just over 2 seconds, about _5× faster than LLD and 25× faster than Gold_​infoq.com. Even for slightly smaller projects, mold tends to at least double the speed of LLD​infoq.com. These gains have made mold very attractive for developers of huge C++ codebases where link time was the last major slowdown in the build cycle. Mold continues to improve: for instance, version 2.36 (2025) introduced further optimizations, yielding an extra 7% speedup when linking Clang on ARM64 and 4% on RISC-V platforms​phoronix.com.

Modern compilers and build systems are increasingly embracing these fast linkers. Projects that have switched to LLD or mold have reported significantly shorter build times, especially in debug builds where linking of large binaries with full debug info can dominate. For example, one large 12-million-line C++ codebase at Mozilla moved from Gold to mold and observed a 3×–8× reduction in link times in practice​

productive-cpp.com​productive-cpp.com. Such improvements directly translate to faster edit–compile–run cycles and improved developer productivity.

Innovations in Incremental and Parallel Linking

Beyond creating faster linkers from scratch, developers have explored incremental and parallel linking techniques to reduce link time:

• Parallel Linking – The idea of exploiting multiple CPU cores for the linking step has been a key to modern linker speed. Traditional GNU ld.bfd was single-threaded, which became a bottleneck on today’s multi-core machines​

  lwn.net​lwn.net. Gold was one of the first to introduce multi-threading in a Unix linker, which is a big reason it could outperform ld (it could resolve symbols and perform relocations in parallel). LLVM LLD and mold take this further by parallelizing almost every phase of linking (reading files, symbol resolution, section layout, relocation, writing output). As a result, on a multi-core system LLD can run more than twice as fast as Gold​lld.llvm.org, and mold even more. The benefit of parallel linking grows with the number of cores – as one comment noted, with CPUs gaining more cores rather than higher single-core speeds, a multi-threaded linker is essential to avoid linking becoming the build bottleneck​lwn.net.

• Incremental Linking – Incremental linking updates an existing binary or library instead of linking from scratch, reusing as much of the previous link result as possible​

  gcc.gnu.org​gcc.gnu.org. This technique has long been used in Microsoft’s linker (for instance, Visual Studio’s linker incrementally links by default for debug builds, greatly speeding up iterative development)​news.ycombinator.com. In the Unix world, however, incremental linking has not been widely adopted. GNU ld and Apple’s ld64 do not support incremental linking​news.ycombinator.com. GNU Gold added an --incremental mode, but it must be explicitly enabled and has limitations​news.ycombinator.com​gcc.gnu.org– as a result it’s rarely used by default in build systems. LLD, despite being new, does not support incremental linking either as of now​news.ycombinator.com.

  The reluctance to implement or use incremental linking on Unix has a few reasons. First, incremental linking adds complexity and can make the linker output nondeterministic or larger in size (due to padding and jump thunks)​

  learn.microsoft.com. Build systems increasingly value reproducible (bit-for-bit identical) binaries, which incremental linking can break since it depends on the previous state of the output file​news.ycombinator.com​news.ycombinator.com. Second, incremental linking itself has overhead: the linker must detect which object files changed, patch the output, and maintain additional data structures. In fact, the gold linker can take almost 30 seconds for a “null” incremental link (where no objects have changed) just due to this bookkeeping, which eats into the benefit​github.com. Because of these issues, some linker developers argue it’s better to make full linking as fast as possible rather than rely on incrementality. As the author of mold put it, “incremental linking is tricky... I wanted to make full link as fast as possible, so that we don't have to think about working around the slowness of full link”​github.com.

  That said, there is renewed interest in incremental techniques. For example, a new project called “Wild” is a Linux linker in development focused on being a very fast incremental linker. Its developer reports that in non-incremental mode Wild is already competitive – linking itself ~48% faster than mold in one test – and now the goal is to add robust incremental linking on top​

  davidlattimore.github.io. The vision is to achieve near-instant link times (on the order of milliseconds) for development by only updating the affected parts of the binary on each edit​davidlattimore.github.io​davidlattimore.github.io. If successful, this would bring Unix linkers closer to the convenience Windows developers have had with incremental linking for years, potentially even enabling advanced features like hot code reloading (updating code in a running program)​davidlattimore.github.io. Wild’s emergence underscores that despite ultra-fast full linkers like mold, incremental linking is still seen as a worthwhile pursuit for cutting build times even further.

• Other Techniques – A related approach to reduce link time is distributed linking, where the work is spread across multiple machines. This is not common for general C/C++ linking due to the difficulty of splitting the work, but in specialized build systems there are features like Incredibuild’s IncrediLink for Visual Studio. IncrediLink combines MSVC incremental linking with a trick: it replaces static library (.lib) inputs with their individual object files, allowing more granular updates and parallelism in linking large projects​

  docs.incredibuild.com​docs.incredibuild.com. This kind of approach highlights that build toolchains can sometimes be tweaked to avoid unnecessary linking work (like skipping static library archiving in favor of directly linking objects) to save time. Another angle is Thin LTO (Link Time Optimization), which was introduced to make LTO viable by splitting heavy optimization work out of the final link phase. With ThinLTO, a “thin” link step happens quickly (just merging index data) and the expensive optimizations are done in parallel on individual modules, thereby preventing a massive slowdown during the final link of an LTO build. While ThinLTO’s main purpose is optimizing code, its design is essentially about reducing link-time overhead of full program optimization.

In summary, parallelism is now a standard feature of fast linkers, and incremental linking—while challenging—remains an area of innovation. Combining both (parallel + incremental) could yield the best of both worlds, and we see early signs of that in experimental tools.

Benchmarks and Case Studies of Linking Speed Improvements

Concrete examples and benchmarks highlight how these developments are paying off in practice:

• Chromium/Chrome Browser: Linking Google’s Chromium browser is a famously intensive task (the final executable is on the order of 1–2 GB). Using traditional tools, linking Chromium could take minutes. With Gold, it improved but was still lengthy (dozens of seconds). LLVM’s LLD brought it down to ~12 seconds in one report​

  infoq.com. Mold reduced this dramatically – one benchmark showed mold linking a 2 GB Chrome executable in ~2.3 seconds, a 5× speed-up over LLD and more than 25× faster than Gold​infoq.com. This showcases how far linker performance has come: what once took over a minute with older linkers can now be done in a couple of seconds with the latest tools.

• Clang/LLVM: The Clang compiler itself (part of LLVM) is a large codebase that produces a big binary. In tests linking Clang (with debug info), GNU ld took 40+ seconds, Gold around 30 seconds, and LLD about 5 seconds – whereas mold linked the same binary in roughly 1.3–1.5 seconds​

  github.com. That’s an enormous improvement, turning a formerly long wait into something almost imperceptible. Even between LLD and mold the difference was significant (5.2s vs 1.35s for Clang 19)​github.com.

• MySQL: A large application like MySQL (nearly 0.5 GB binary) saw linking drop from ~11 seconds with ld.bfd to ~1.6 seconds with LLD, and just ~0.46 seconds with mold​

  github.com. In this case LLD was already about 7× faster than ld, and mold a further 3–4× faster still.

• Large C++ Project at scale: One report from a company with a 12-million line C++ codebase (with heavy template usage) described their build improvements over the years​

  productive-cpp.com​productive-cpp.com. Initially, linking was a pain point. Adopting Gold in 2013 provided a “noticeable reduction” in link times​productive-cpp.com. Later they experimented with LLD around 2017, which was faster than Gold, though had some compatibility issues at the time​productive-cpp.com. In 2021 they integrated mold and saw major wins – linking that previously took on the order of tens of seconds was cut down multiple-fold. The author titled their experience as achieving “3×–8× link time speedups” by using mold in place of older linkers​productive-cpp.com. This case illustrates that even after using Gold and trying LLD, mold was able to bring further dramatic reductions in build time, validating that continuous innovation in linkers yields real-world benefits.

• Rust and MSVC builds: In the Rust community, where the compiler can use either the system linker or LLD, users have observed differences in incremental build times. At one point LLD was known to speed up Windows builds, but as of 2023 it was noted that Microsoft’s linker had improved to the point that using LLD no longer gave a big benefit​

  users.rust-lang.org. This suggests that even proprietary tools have not stood still – MSVC’s linker has gotten faster (possibly through multi-threading or other optimizations) and can handle typical incremental rebuilds fairly quickly now. Nonetheless, for very large Rust binaries on Linux, using mold is reported to shave many seconds off link time compared to default linkers, which is why some developers opt into mold or LLD via configuration​productive-cpp.com​productive-cpp.com.

These benchmarks underscore a clear trend: linking that used to take tens of seconds (or even minutes) has been brought down to a few seconds or less in many scenarios by switching to modern linkers. For developers, this means less time waiting and more time coding. The improvements are especially pronounced for debug builds (with full debug info) of large applications, where the link step often dominated; tools like mold handle those cases with ease, in some instances making the linker no longer the slowest part of the build at all.

Challenges and Future Trends in Linker Optimization

Despite the impressive gains so far, several challenges remain in pushing linker performance even further:

• Balancing Speed with Correctness and Determinism – One challenge is that making linkers faster (through parallel threads or caching results) can introduce nondeterministic outputs if not carefully managed. Build reproducibility is important for many projects (especially OS distributions and security-conscious builds). Linkers like LLD had to sometimes choose a slightly slower algorithm to preserve deterministic output​

  news.ycombinator.com. For example, parallel string table merging could have been faster but produced inconsistent ordering, so a deterministic approach was used instead​news.ycombinator.com. Ensuring that faster linking doesn’t compromise the exactness of the output (or introduce subtle bugs) is an ongoing concern.

• Memory and Resource Usage – Faster linkers often trade off memory for speed. Mold’s philosophy of loading and processing everything in parallel means it can use a large amount of RAM when linking a huge program. While most developer machines can handle this for typical projects, extremely large applications can stress memory and I/O subsystems. There’s a balance between using more memory to avoid slow disk accesses and not consuming too much. In practice, this hasn’t been a blocker for adoption, but it’s an area of focus (for instance, Wild’s author is cautious about handling “large model” executables that might exceed certain memory/address bounds​

  davidlattimore.github.io). Future linkers might incorporate smarter memory management or even out-of-core algorithms if code sizes keep growing.

• Debug Information Processing – A significant portion of link time (especially in C++ with -g) can be spent merging and writing debug info (DWARF sections). This is largely I/O-bound. Techniques like split DWARF (-gsplit-dwarf) keep debug info in separate files to lighten the linker’s work. While linkers themselves can’t fully solve the overhead of debug data, improvements in compiler outputs and formats (e.g., more use of index tables or compression) can indirectly speed up linking. Some linkers might also multithread the writing of debug info or bypass it. This remains an area where there’s room to optimize how much work the linker must do versus deferring or parallelizing debug data handling.

• Incremental and Interactive Builds – As mentioned, a frontier for linkers is enabling incremental linking reliably on Linux/Unix. The Wild project (and possibly others in the future) aims to deliver a production-quality incremental linker, which could change how developers work by virtually eliminating link time in the edit-run cycle. If Wild or similar efforts succeed, we may see a shift where Unix builds default to an incremental linking mode for debug builds (much as MSVC does), with full linking only for final releases. Additionally, the idea of hot code reloading or dynamic relinking of running programs could blur the line between compile/link and execution, enabling new development workflows (for example, updating a server’s code on the fly). These are still experimental ideas, but they are on the horizon as linkers get faster and more sophisticated.

• Integration with Build Systems and Compilers – Another trend is better integration of the linker into overall build pipelines. For example, LLD can be used as a library, and some have proposed closer coupling between the compiler and linker to avoid duplicate work. ThinLTO is one example where the traditional barrier between compile and link was adjusted to improve performance. We may see compilers and linkers coordinating more – e.g., compilers providing the linker with pre-digested relocation info or symbol indexes to speed up the link stage. Build systems might also become linker-aware, scheduling linking tasks in parallel or caching link outputs. Tools like Bazel and CCache already cache compile results; a future extension could cache partial link results for static libraries or similar. All of these ideas aim at shaving off redundant work in the linking process.

• New Linker Projects and Competition – The landscape is still evolving. With Gold’s retirement, LLVM lld and mold are the main open-source players, but as we’ve seen, new projects like Wild are emerging to tackle specific niches (incremental builds, extreme low-latency linking). There’s also ongoing work in the LLVM community to improve lld (for instance, to better handle huge numbers of sections or to utilize I/O more efficiently). Competition drives innovation, so having multiple high-performance linkers could lead to sharing of ideas and faster progress. Even in proprietary space, if Unix linkers get dramatically faster, Microsoft and Apple may respond by further accelerating their own linkers to stay on par.

In conclusion, the recent developments in linker technology have significantly reduced link times for large applications through smarter algorithms, parallelism, and new linker implementations. Traditional linkers like GNU ld have sped up, modern linkers like LLVM lld and mold have set new performance standards, and upcoming innovations (incremental linking, new projects like Wild) promise to continue this trajectory. While challenges like maintaining determinism, managing resources, and handling ever-growing codebases exist, the overall trend is very positive: linking is becoming less and less of a build-time burden. Faster linkers translate directly into faster build-test cycles, benefiting developers by increasing productivity and enabling quicker iterations. With continued focus on performance, future linkers might make the link step so fast that it fades into the background, regardless of project size – a scenario that once seemed unimaginable for C/C++ development, but now is within reach given the breakthroughs in the past few years.

https://chatgpt.com/share/67a0b181-6fa4-800c-a52c-674cd7c51a40