42. 11.2 性能优化

3天前发布

引言：当”施工队长”开始讲究”效率”

在前面的章节中，我们的CMake”施工队长”已经练就了一身过硬的本领：从看图纸（Target）到办交房（Install），从跑海外工程（交叉编译）到接待各路监理（IDE集成），可谓是十八般武艺样样精通。但如果你的项目是个真正的”超级工程”——几千个源文件、上百个子模块、依赖数十个外部库——你可能会发现，每次修改一小行代码，CMake都要”思考人生”好几秒甚至几十秒。这种等待，就像看着施工队长每次开工前都要重新清点一遍全城的砖块，效率实在太低了。

这一节，我们要教这位队长几招”时间管理术”：如何在保证工程质量的前提下，让CMake的配置（Configure）和生成（Generate）阶段跑得更快。这不仅是大型项目的必修课，也是中小项目养成良好习惯的关键。

要点1：减少CMake配置时间——避免重复的全局操作

CMake的配置阶段（Configure）就像队长每天的晨会：他要检查一遍所有图纸、材料和工艺要求，确认没问题后才会喊”开工”。问题在于，如果晨会的内容每次都是一样的，或者队长每次都要翻遍整个仓库清点库存，那这段晨会时间就纯粹是浪费。

1.1 警惕”全局扫描”型命令

最常见的性能杀手之一，是在每次配置时都执行大规模的文件系统扫描。最典型的例子是file(GLOB_RECURSE ...)。虽然它写起来省事，但CMake默认不会在磁盘文件变化时自动重新配置（除非配合CONFIGURE_DEPENDS，但那反而会让每次文件改动都触发重新配置，更加耗时）。

在大型项目中，显式列出源文件（或者使用代码生成脚本维护文件列表）通常比递归GLOB更高效。如果必须使用GLOB，尽量缩小搜索范围：

# 避免：扫描整个项目
file(GLOB_RECURSE SOURCES "*.cpp")  # 慢且不可控

# 推荐：只在特定目录，显式列出或分段扫描
set(SOURCES
    src/core/main.cpp
    src/core/engine.cpp
    src/utils/helpers.cpp
)

1.2 避免重复查找依赖包

find_package在找不到包时会执行大量搜索逻辑。虽然CMake会缓存结果到CMakeCache.txt中，但如果你的CMakeLists.txt中充斥着大量的find_package调用，且没有合理的REQUIRED/QUIET控制，配置阶段就会像队长反复打电话给供应商确认”水泥到了吗”一样低效。

优化策略是：把常用的外部依赖查找集中在项目的顶层或专门的依赖管理模块中，通过接口库（Interface Library，见3.2节）一次性封装，供各子模块链接，而不是让每个子目录都重复find_package(Boost)。

1.3 使用include_guard防止重复加载

在模块化项目中，同一个.cmake模块可能被多次include。CMake 3.10+ 提供的include_guard()命令能避免模块内容的重复执行，就像给工具箱贴上了”已清点”标签：

# cmake/modules/UtilFunctions.cmake
include_guard(GLOBAL)  # 全局级别：整个项目中只处理一次

function(my_helper)
    # ...
endfunction()

要点2：缓存变量策略——合理设置缓存避免重复配置

CMake的缓存（CMakeCache.txt）是队长的”备忘录”：第一次 configure 时，他会把各种选项、路径、编译器信息写进去，下次就直接读备忘录，不用再问一遍。但如果队长乱写备忘录——比如把临时草稿也当成正式文件——下次他就会搞混，甚至不得不把备忘录撕了重写（删除缓存重新配置）。

2.1 分清”用户选项”和”内部变量”

很多CMake脚本滥用set(... CACHE ... FORCE)，这相当于队长强行把每根钉子的位置都写进永久档案，还不允许别人修改。正确的做法是：

用户可配置选项：使用option()或set(... CACHE TYPE "doc")，不要加FORCE，让用户可以通过GUI或命令行覆盖。
内部临时变量：使用普通变量set(MY_VAR "value")，或者如果必须进缓存，使用INTERNAL类型，且只在首次配置时设置。

# 错误：每次运行都会强制覆盖缓存，导致CMake认为配置有变化
set(MY_FLAG ON CACHE BOOL "My flag" FORCE)

# 正确：只在未定义时设置默认值
if(NOT DEFINED MY_FLAG)
    set(MY_FLAG ON CACHE BOOL "My flag")
endif()

# 更推荐：用于布尔开关
option(MY_FLAG "Enable my feature" ON)

2.2 避免在全局作用域频繁修改缓存

有些开发者喜欢在顶层CMakeLists.txt里用一大堆set(... CACHE ...)来”初始化环境”。这会导致每次重新配置时，CMake都要检查这些缓存项的合法性，并可能触发依赖它们的子目录重新生成。尽量把缓存变量的集中定义放在项目早期，且遵循”写一次，读多次”的原则。

2.3 缓存变量与构建类型

对于多配置生成器（如Visual Studio、Xcode），不要在缓存里硬编码CMAKE_BUILD_TYPE（它只在单配置生成器如Makefile、Ninja中有效）。错误的缓存设置会导致CMake反复调整内部状态：

# 不推荐：在多配置生成器中会制造混乱
set(CMAKE_BUILD_TYPE Release CACHE STRING "Build type" FORCE)

# 推荐：仅在单配置环境下提供默认值
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
    set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Choose the type of build." FORCE)
    set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
endif()

要点3：大型项目的CMake性能调优——分层配置与延迟加载

当项目规模膨胀到成百上千个目标（Target）时，CMake的解析时间会成为瓶颈。这时我们需要改变组织结构，从”扁平化管理”转向”分层授权”。

3.1 条件化子目录加载

不是所有子模块在每次构建时都需要。使用条件判断和选项控制，避免把不相关的目录统统加进来：

option(BUILD_TESTING "Build tests" ON)
option(BUILD_EXAMPLES "Build examples" OFF)

if(BUILD_TESTING)
    add_subdirectory(tests)
endif()

if(BUILD_EXAMPLES)
    add_subdirectory(examples)
endif()

这不仅减少了配置时间，也减少了IDE加载的项目索引量。对于第三方库，使用EXCLUDE_FROM_ALL可以避免构建你不需要的目标：

add_subdirectory(third_party/some_lib EXCLUDE_FROM_ALL)

# 只构建你明确依赖的目标，而不是some_lib里的所有测试、示例
target_link_libraries(my_app PRIVATE some_lib::core)

3.2 延迟加载：cmake_language(DEFER)

CMake 3.19 引入了一个强大的命令cmake_language(DEFER)，它允许你把某些非关键操作推迟到当前目录的CMake脚本处理完毕之后再执行。这就像队长说：”先把今天的图纸看完，午休时再整理工具箱。”

# 在当前目录处理结束后，执行某些诊断或汇总逻辑
cmake_language(DEFER CALL message STATUS "Configuration of ${CMAKE_CURRENT_SOURCE_DIR} finished.")

# 甚至可以延迟执行自定义函数
function(final_summary)
    message(STATUS "Total targets so far: ${GLOBAL_TARGET_COUNT}")
endfunction()

cmake_language(DEFER CALL final_summary)

虽然这个命令本身不会直接减少总工作量，但在复杂的分层项目中，它可以帮助你优化执行顺序，把轻量级的配置工作提前，重量级的验证工作延后，从而提升整体流畅度。

3.3 使用预编译的外部依赖（Superbuild模式回顾）

回顾4.4节的Superbuild模式：对于那些庞大且变动极少的第三方库（如Boost、Qt、OpenCV），不要每次主项目配置时都重新扫描它们的构建树。更好的做法是：

用Superbuild或ExternalProject预先编译安装它们到某个前缀目录；
主项目通过CMAKE_PREFIX_PATH直接指向已安装的包，使用find_package快速导入；
主项目的CMake不再解析第三方库内部成百上千的目标。

3.4 精简PUBLIC依赖链

在大型项目中，一个目标的PUBLIC依赖会像滚雪球一样传递给所有下游目标。CMake在配置阶段需要解析整个依赖图，如果这张图强耦合、环多、层级深，解析时间就会爆炸。

优化建议：

优先使用PRIVATE链接，只在真正需要接口暴露时使用PUBLIC；
使用接口库（Interface Library）聚合常用依赖，减少链接边的数量；
定期检查并打破循环依赖（参考2.3.7节）。

3.5 诊断配置瓶颈

如果你想知道CMake的时间到底花在哪了，CMake 3.18+ 提供了--profiling-format=google-trace选项，可以生成Chrome浏览器可打开的JSON性能分析文件：

cmake -B build --profiling-format=google-trace --profiling-output=cmake_prof.json

用Chrome的chrome://tracing或Edge的edge://tracing打开它，你能直观看到哪个CMakeLists.txt、哪个find_package、哪个函数调用是时间大户。这是给队长配的”工期记录仪”，用数据说话，精准优化。

小结：让CMake”跑”得更快

性能优化不是大型项目的专利。从小项目开始就养成好习惯——显式管理源文件、合理使用缓存、避免全局重复操作——能让你的CMake在工程规模增长时依然保持轻盈。

记住这三条心法：

少做重复功：全局扫描、重复查找、模块重复加载，能省则省；
缓存要精明：区分用户选项和内部变量，不滥用FORCE，不写多余的缓存；
结构决定性能：分层配置、按需加载、精简依赖链，让CMake的解析复杂度保持在合理范围。

下一节（11.3），我们将探讨CMake的策略（Policy）系统——当新旧行为发生冲突时，CMake是如何通过策略机制优雅地实现向前兼容的。这相当于给队长配发了一本《施工规范更新手册》，让他既能兼容老工艺，又能无缝切换到新标准。敬请期待！

测试标签

评分

欢迎为Ta评分