C++预编译头文件是否会减慢链接时间？构建耗时问题咨询

你观测到的「预编译头降低单文件编译耗时、提升链接耗时、全量构建总耗时无优势」的现象不是配置错误，是预编译头默认工作机制下的普遍预期表现，在头文件包含大量模板、内联实现（比如header-only库）的场景下尤其明显。

预编译头的本质是把你写在pch.h里的所有头文件，提前做一次完整的词法分析、语法分析、模板初步实例化，生成二进制快照供所有cpp编译时直接复用，省掉每个cpp重复解析同一批头文件的开销——这就是单cpp编译.obj速度变快的原因。
但默认配置下，预编译头生成的快照里，会把所有头文件包含的内联函数、模板实例、COMDAT段无差别注入到每个引用PCH的cpp生成的目标文件里。链接阶段需要对所有目标文件里重复的符号做合并、对未引用的段做剔除，冗余符号越多，链接耗时越长。你测试用的spdlog、100个外部头文件都属于典型的高冗余符号来源，链接耗时翻倍完全符合机制预期。
另外你测试的都是全量构建场景：预编译头本身生成就要花一次完整解析所有头文件的时间，再叠加链接的额外开销，总耗时和不使用PCH持平甚至反超是正常的。预编译头的核心收益场景是日常开发的增量构建——也就是你只修改了1-2个业务cpp，不需要重新解析所有依赖头文件的时候，这部分编译速度的提升通常远大于链接的额外开销。

• 严格筛选PCH的包含内容：只往pch.h里放长期稳定不修改、被项目中超过半数cpp引用、本身解析成本极高的头文件，比如STL头文件、系统SDK头文件、第三方稳定库的头文件。不要图省事把目录下所有头文件全塞进去，也不要放自己项目里经常改动的业务头文件，否则既会增加PCH本身的生成耗时、提升链接冗余，还会因为PCH频繁失效拖慢增量构建。
• 开启编译器和链接器的冗余段优化，从根源降低链接开销：
  如果你用MSVC工具链，在CMake里加如下配置：

  target_compile_options(${PROJECT_NAME} PRIVATE /Gy /Oi /Zf)
  target_link_options(${PROJECT_NAME} PRIVATE /OPT:REF /OPT:ICF)
  

  如果你用GCC/Clang工具链，加如下配置：

  target_compile_options(${PROJECT_NAME} PRIVATE -ffunction-sections -fdata-sections)
  target_link_options(${PROJECT_NAME} PRIVATE -Wl,--gc-sections -Wl,--icf=all)
  

  这组配置会让编译器把每个函数、全局数据单独存为独立段，链接时自动剔除未被引用的段、合并完全相同的重复段，可以把PCH带来的额外链接开销降低70%以上。
• 不要用全量clean构建的耗时衡量PCH收益：日常开发中90%以上的构建都是改少量代码的增量构建，这时候PCH不需要重新生成，单cpp编译的速度提升会非常明显，整体耗时优势会远大于链接的少量额外开销。
• 中大型项目可以把PCH和CMake Unity Build组合使用，进一步降低整体编译链接的冗余开销，比单独用PCH的收益高30%左右。

内容的提问来源于stack exchange，提问作者James Dhanoa