使用 Unity Build 加速 CMake 编译

cater · 发表于 2020-11-25 09:09

本文使用 Zhihu On VSCode 创作并发布

一、使用效果

未使用 Unity Build

未使用 Unity Build
使用 Unity Build

使用 Unity Build
二、原理说明

C/C++ 的编译系统和其他高级语言存在很大的差异。
其他高级语言中，编译单元是整个module，即module下所有源码，会在同一个编译任务中执行。
而 C/C++ 中，因为历史遗留问题（早年的硬件内存不支持同时加载整个项目的源码进行编译），编译单元是以文件为单位。
即，C/C++ 的编译方式是这样的：

以上编译方式存在几个很严重的性能问题：

每个编译单元，都需要独立解析所有包含的头文件:
每个源文件独立编译，导致编译优化时只能基于本文件内容进行优化，很难跨编译单元提供代码优化；基于问题2，C/C++ 跨编译单元的优化只能交给链接器，而链接阶段是单进程，无法并行加速，导致大项目链接极慢。

问题1可以通过并行编译解决，但只是治标不治本，总开销依然有大量的资源浪费；也可通过预编译头PCH解决，与本方法差别见后文。
问题2目前暂无解决手段，新标准的module功能有望改善此问题。
问题3可以通过动态库方式降低链接耗时，即拆分为多个二进制目标。（静态库无效，静态库本质上相当于把 .o/.obj 做了一次打包，最后生成二进制时合并到链接器中）
本文提出一个 Unity Build 思路，可以大幅提升编译速度，原理如下：

源代码

该方式规避了问题1中的额外开销，对于越复杂的代码（模板/宏用得多），编译速度提升越快。
同时，对于1.2的模板多次实例化问题，Unity Build 只会实例化一次模板，对问题3的链接也有一定加速。
但考虑到多进程并行编译，并不是把所有代码都打包到同一个unity_build.cpp中效果最好。
打包思路可以参考module，即将同一个模块的源代码打包为一个文件，这样该模块中大量公用的头文件就可以避免被多次解析。
三、与 PCH 区别

1、pch不能针对性地对一部分代码生效。比如只想把某三个文件打包编译，pch就不适用。如果专门写个add_library把他们仨单独打包又太麻烦了，还得配置target_include_directories啥的。如果不用target_xxx系列指令的话，又不太符合 target-based 的 Modern CMake 风格，少了内味/Taste。
2、这个方法比pch更激进，相当于把所有头文件全都塞一起了——用pch开发的时候，不可能所有cpp里只有一行#include <stdafx.h>吧。
四、参考代码

# Unity Build 函数，将输入的文件列表打包输出为一个 unit_build.cpp文件
# input_src：文件列表，调用时通过字符串传递，如 &#34;${PROJECT_SRC}&#34;。若在.cmake文件中调用，则需要提供绝对路径
# output_file：输出文件，存放在 ${CMAKE_BINARY_DIR}/${output_file}，即build目录
function(UNITY_BUILD output_file input_src)
file(WRITE ${CMAKE_BINARY_DIR}/${output_file} &#34;// ${output_file}\n&#34;)
foreach(filename ${input_src})
file(APPEND ${CMAKE_BINARY_DIR}/${output_file} &#34;#include \&#34;${filename}\&#34;\n&#34;)
endforeach()
message(&#34;Generate unity build file: ${CMAKE_BINARY_DIR}/${output_file}&#34;)
endfunction(UNITY_BUILD)
# 使用范例
set(MODULE_SRC
a.cpp
b.cpp
c.cpp
)
UNITY_BUILD(module_unity_build.cpp &#34;${MODULE_SRC}&#34;)
add_executable(${PROJECT_NAME}
main.cpp
${CMAKE_BINARY_DIR}/module_unity_build.cpp
)

复制代码

注意：

		自动登录	找回密码
密码			立即注册

[笔记] 使用 Unity Build 加速 CMake 编译

本帖子中包含更多资源