# Why are DLL builds bottlenecked by Linker calls?

**URL:** https://discourse.cmake.org/t/why-are-dll-builds-bottlenecked-by-linker-calls/13973
**Category:** Code
**Tags:** os:windows, gen:vs
**Created:** [April 23, 2025, 4:55pm UTC](https://discourse.cmake.org/t/why-are-dll-builds-bottlenecked-by-linker-calls/13973 "2025-04-23T16:55:02Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![zachdanz](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachdanz/32/5522_2.png) [@zachdanz](https://discourse.cmake.org/u/zachdanz)
#### Post date: [April 23, 2025, 4:55pm UTC](https://discourse.cmake.org/t/why-are-dll-builds-bottlenecked-by-linker-calls/13973/1 "2025-04-23T16:55:02Z")

</div>

Hey Cmake Community!

We build our project statically as well as dynamically, and we have noticed that when building with DLLs, the build is severely bottlenecked compared to its static lib [OPTIMIZE\_DEPENDENCIES — CMake 4.0.1 Documentation](https://cmake.org/cmake/help/latest/prop_tgt/OPTIMIZE_DEPENDENCIES.html) counterpart. Looking at the build under a dependency build graph like the GUI of IncrediBuild, you can see that the DLL build is waiting for Linker calls to happen and not compiling in the meantime.

We don’t actually need to wait for this. Each dll and pdb doesn’t need to exist until _the project that depends on it is linking_ but instead cmake’s produced projects are causing the overall build to wait for those dlls _before even beginning the compile step of the dependent jobs_

Any thoughts? Am I doing something wacky?

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 24, 2025, 6:37pm UTC](https://discourse.cmake.org/t/why-are-dll-builds-bottlenecked-by-linker-calls/13973/2 "2025-04-24T18:37:41Z")

</div>

CMake’s code model was developed prior to the existence of Ninja, at which time all build systems for which we had generators would build each target to completion before its dependents even start to build. No concurrency across dependent targets was achievable. Therefore custom commands in one target are allowed to generate files at build time that are consumed by other dependent targets, such as header files that may be included by the dependents’ sources. When the Ninja generator was introduced, we had to insert conservative dependency edges to implement this target ordering for compatibility with existing projects. Over time we’ve found ways to lift some of these dependencies.

`OPTIMIZE_DEPENDENCIES` was developed specifically with static libraries and object libraries in mind. Further work could probably extend some of its effects to shared libraries.

---

<div class="post-metadata">

### Author: ![zachdanz](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachdanz/32/5522_2.png) [@zachdanz](https://discourse.cmake.org/u/zachdanz)
#### Post date: [April 28, 2025, 11:03pm UTC](https://discourse.cmake.org/t/why-are-dll-builds-bottlenecked-by-linker-calls/13973/3 "2025-04-28T23:03:24Z")

</div>

Hey Brad - thanks for the context and history. That is helpful for understanding why this feature is missing for many generators.

Do you know if extending this developer iteration efficiency work is planned for shared libraries? Happy to be part of a conversation there!