预编译头与.so目标文件的编译执行速度对比及迁移优化咨询

1. 预编译头与.so目标文件的编译/执行速度对比 #

• 编译速度：把稳定功能编译成.so后，编译速度会比仅用预编译头快得多。预编译头只是缓存头文件的编译结果，只要头文件或其依赖的代码有变动，还是得重新处理；而.so一旦编译完成，只要这部分稳定功能不修改，主应用编译时只需要链接它，完全跳过这部分代码的编译步骤，节省大量时间。
• 执行速度：两者几乎没有差异。.so是动态链接，加载时会有极轻微的开销，但运行阶段的性能和预编译头生成的代码完全一致，日常场景下这点开销可以忽略不计。

2. 转为.so模式后是否仍需预编译头 #

需要，但可以调整使用策略：

• 主应用里依旧可以保留预编译头，用来缓存那些频繁修改的公共头文件（比如主应用的配置头、正在开发的新模块头文件），减少主应用自身的编译耗时。
• 对于.so对应的稳定头文件，因为这些文件基本不会修改，要么把它们加入预编译头进一步减少主应用的头文件解析时间，要么如果完全没变动，也可以不用放进预编译头——反正主应用编译时只是读取头文件做类型检查，不会重复编译.so里的实现代码。

3. 缩短项目更新耗时的其他建议 #

• 优化增量构建：确保Make、CMake这类构建系统正确识别文件依赖，只编译修改过的文件，避免全量构建。比如用cmake --build . --target <具体模块>只编译更新的部分。
• 开启并行编译：利用多线程加速编译，比如Make用-j$(nproc)，CMake用--parallel $(nproc)，把CPU核心都用上。
• 拆分独立模块：把项目拆成更多功能单一的子模块（比如多个.so），更新时只编译修改的模块，缩小编译范围。
• 用ccache缓存编译产物：ccache会缓存编译过的目标文件，就算清理了构建目录，也能快速恢复之前的编译结果，对频繁编译的项目提升很明显。
• 减少头文件依赖：能用前向声明的就不要直接包含头文件，减少编译时的依赖传递，避免因为某个头文件修改导致大量文件重新编译。
• 精简编译配置：开发阶段关闭不必要的调试信息、用O0优化等级加快编译；稳定模块可以开启O2优化，平衡编译和运行速度。

内容的提问来源于stack exchange，提问作者J.Nowicky