ScyllaDB 编译耗时分析用 ClangBuildAnalyzer 定位拖慢构建的头文件与模板【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbScyllaDB 的构建时间自项目第一天起就是核心痛点——仓库中的 docs/dev/compilation-time-analysis.md 明确指出ScyllaDB 的 issue #1 就是关于构建过慢的。在模板密集型 C 代码Seastar 与 ScyllaDB中模板实例化与代码生成的耗时远超源码解析两个等长的头文件可能一个只增加毫秒级开销、另一个却拖慢整秒。本文基于该官方开发者文档完整讲解如何用 Clang 的-ftime-trace选项配合 ClangBuildAnalyzer 工具测量、聚合、解读编译时间数据从而找到最昂贵的头文件与模板实例化并验证代码修改对构建性能的实际影响。读完本文你将掌握一套可复制的构建性能剖析 → 修改 → 验证的完整工作流。为什么头文件体积不等于构建开销文档首先给出了一个关键认知C 编译器时代编译时间与源码量基本成正比减少不必要的头文件包含是唯一手段。但在现代 C 中模板实例化和代码生成的时间开销比单纯解析高出几个数量级。这意味着优化目标不再是减小头文件而是减少昂贵模板的重复实例化次数以及打断不必要的间接包含链。ScyllaDB 的构建系统正是围绕这一认知设计的。从源码结构看configure.py 中定义了 dev、release、debug、sanitize 等构建模式其中 dev 模式的定位就是optimized for fast build timesconfigure.py它使用-O2、不生成调试信息。而构建脚本在生成 build.ninja 时针对scylla主程序启用了预编译头-fpch-instantiate-templates编译stdafx.hh.pch见 configure.py——这也是为什么模板开销统计仍会暴露问题PCH 无法消除模板在不同编译单元中的重复实例化。安装 ClangBuildAnalyzerClangBuildAnalyzer 是一个开源工具用于聚合所有源文件的-ftime-trace日志判断哪些头文件和模板最拖慢构建。安装步骤git clone https://github.com/aras-p/ClangBuildAnalyzer然后用make -f projects/make/Makefile构建并将产物build/ClangBuildAnalyzer加入 PATH。注意该工具只依赖 Clang 的 trace 输出格式不需要修改 ScyllaDB 仓库本身。开启 -ftime-trace两种官方入口文档给出的标准做法是在 Scylla 工作目录中先清理旧构建目录避免把已删除源文件或无关构建模式的旧.json计入统计rm -r build然后重新运行configure.py生成 build.ninja并追加-ftime-trace到编译命令./configure.py --disable-dpdk --cflags-ftime-trace--cflags参数在 configure.py 中定义为 Extra flags for the C compiler其值最终会进入每个编译模式dev/release 等的lib_cflags并透传给 build.ninja 中所有 C 编译规则。此外仓库还提供了两个更便捷的等价入口可视为同一机制的封装--time-trace参数ninja 后端configure.py 中显式定义了--time-trace开关其帮助文本说明Each .o produces a .json file analyzable with ClangBuildAnalyzer or chrome://tracing。在源码内部当该参数开启时-ftime-trace同样被追加到user_cflagsconfigure.py。因此./configure.py --time-trace与--cflags-ftime-trace效果一致且语义更清晰。CMake 后端若使用./configure.py --use-cmake构建cmake/mode.common.cmake 提供了Scylla_TIME_TRACE选项用法为cmake -DScylla_TIME_TRACEON ...它强制要求 Clang 编译器否则直接FATAL_ERROR并在满足条件时对全部编译添加-ftime-trace。构建并收集每文件的 JSON trace开启 trace 后只需构建单一构建模式的scylla主可执行文件文档以 dev 模式为例ninja build/dev/scylla构建过程中每个被编译的源文件都会在构建目录下生成一个独立的JSON 文件包含该文件的编译耗时分析。例如编译cdc/generation.cc会产生build/dev/cdc/generation.json。这些 JSON 文件采用 Chrome trace 格式可以单独用各种工具查看包括 Google 的 Perfetto UI可通过chrome://tracing加载。但单文件视角回答不了整体最慢的是哪个头文件/模板这个问题——这正是 ClangBuildAnalyzer 的价值所在ClangBuildAnalyzer --all build/dev build/dev/clba.bin ClangBuildAnalyzer --analyze build/dev/clba.bin | less--all把所有.json合并为一个二进制文件clba.bin--analyze则产生人类可读的报告。迭代使用修改代码后的正确复测方法文档给出了四条重要的实操细节直接影响测量正确性首次构建会全量重编。因为-ftime-trace改变了命令行即使之前用 ccache 构建过第一次带 trace 的 ninja 也必须全部重编。并且 ccache 在-ftime-trace启用期间会主动放弃缓存ccache 官方 release notes 中仅说明too hard。改动后只需重跑 ninja 与 ClangBuildAnalyzer 两步。ninja 只重编受影响的源文件这些文件对应的.json会更新ClangBuildAnalyzer 会结合新旧 JSON 生成最新的统计。删除源文件要手动清理残留 JSON。被移除源文件的.json仍留在build/dev/下会向统计中注入错误信息需手动删除该 JSON或删除整个build目录重来。不再需要测量时去掉--cflags-ftime-trace或--time-trace重跑 configure.py 即可恢复普通构建。用 du 估算构建时间收益文档指出了一个实用的替代指标构建时间测量精度不高小幅改进难以直接观测但 ScyllaDB 团队观察到构建时间与产出的目标文件总大小高度相关du -bc build/dev/**/*.o其原理是 C 编译器慢通常因为它生成了巨量代码。因此这条du命令的输出可作为本次修改节省了多少编译工作量的良好估计量——它比墙钟时间更稳定、可重复。解读 ClangBuildAnalyzer 报告六类输出逐段拆解ClangBuildAnalyzer --analyze build/dev/clba.bin的输出由多个榜单组成文档按信息价值从高到低逐一解释。以下以文档中的真实输出为例。1. Files that took longest to parse / codegen这两个段落列出解析前端和代码生成后端最耗时的源文件。文档当时的头号问题是messaging_service.cc**** Files that took longest to parse (compiler frontend): 84164 ms: build/dev/message/messaging_service.o ... **** Files that took longest to codegen (compiler backend): 135417 ms: build/dev/message/messaging_service.o即仅约 1,376 行代码当前仓库中 message/messaging_service.cc 为 1,500 余行与文档描述一致的源文件前后端合计消耗约 4 分钟 CPU 时间。文档诚实地指出这类信息告诉我们哪个文件慢却不解释为什么慢。它的实用价值有限——最多用于把最慢的文件排在并行构建最前面避免 straggler或把大文件进一步拆分。2. Templates that took longest to instantiate最有价值的一节**** Templates that took longest to instantiate: 385738 ms: fmt::detail::vformat_tochar (552 times, avg 698 ms) 197016 ms: boost::basic_regexchar::assign (329 times, avg 598 ms) 195522 ms: ser::deserializeseastar::simple_memory_input_stream (1617 times, av g 120 ms) ...这份榜单上的模板有两个共同特征被很多源文件使用常因为出现在被广泛包含的头文件中且单次实例化极其昂贵上例中vformat_tochar每次实例化高达 0.7 秒。针对它们文档给出三条具体优化路径减少实例化次数——例如避免在热门头文件中包含该模板或减少对该头文件的包含改写模板减少其内部嵌套的其他模板使用extern template显式实例化让模板只实例化一次。对比前一小节可以看到差异的本质单个函数只编译一次再慢也只是常数而模板是乘以包含它的编译单元数量——552 次 × 698ms ≈ 386 秒这就是模板榜单值得优先处理的原因。3. Template sets that took longest to instantiate*** Template sets that took longest to instantiate: 640682 ms: std::unique_ptr$ (31372 times, avg 20 ms) 581171 ms: std::__and_$ (351772 times, avg 1 ms)template set把同一模板族的所有具体化归并统计。文档认为这一节直接可用性较低我们只能寄望其他改动顺带减少std::unique_ptr的实例化次数没有直接可操作的手段。4. Functions that took longest to compile**** Functions that took longest to compile: 2899 ms: cql3_parser::CqlParser::cqlStatement() (build/dev/gen/cql3/CqlParser.cpp) 2144 ms: replica::database::setup_metrics() (replica/database.cc)可以挑个别函数看看为何慢文档举例alternator::stats::stats()这样很短的函数因 Boost options 的宏技巧耗时整秒。但总体上这一节不值得深挖因为每个函数只编译一次优化收益有上限——这与模板被编译数百次的情形形成鲜明对照。5. Function sets that took longest to compile / optimize与上一节类似但针对模板函数可被编译多次*** Function sets that took longest to compile / optimize: 57092 ms: fmt::v9::appender fmt::v9::detail::write_int_noinline$(...) (1071 times, avg 53 ms) 44361 ms: fmt::v9::detail::format_dragon(...) (357 times, avg 124 ms)这一节帮助从函数体角度交叉印证模板榜单——例如 fmt 库的格式化路径在这里和模板实例化榜单中反复出现说明其是构建开销的重灾区。6. 最昂贵头文件文档称最有趣的段落之一1086240 ms: replica/database.hh (included 139 times, avg 7814 ms), included via: 47x: query_processor.hh wasm.hh 46x: direct include 14x: schema_registry.hh 6x: user_function.hh wasm.hh 5x: cql_test_env.hh 4x: column_family.hh ...该段落的信息密度最高包含三层内容总开销replica/database.hh累计 1086 秒当时约占总构建时间 6%被包含 139 次、平均每次约 8 秒包含链统计139 个包含者中只有 46 个是直接包含其余经过wasm.hh、query_processor.hh、schema_registry.hh等头文件间接引入——这些间接包含是否必要正是需要逐一审查的对象优化方向减少database.hh的包含、拆分它、或让它做的事更少。注意头文件开销是高估值文档特别强调1086 秒这个数字是过估计。实际删掉database.hh不会减少 1086 秒编译时间原因是database.hh包含的其他头文件、实例化的其他模板会记账到这个头文件名下——因为它恰好在某个编译单元中最先使用了这些模板。但其他头文件同样会用到它们即使删掉database.hh它们照样会被实例化。文档的结论是不实际动手试一下无法知道真实收益。因此对榜单应该排序参考、实测验证这正是下一节du度量存在的原因。用 ClangBuildAnalyzer.ini 定制报告ClangBuildAnalyzer 的每个榜单默认只展示固定数量的 Top N 条目。文档介绍了ClangBuildAnalyzer.ini配置机制并给出了作者实际使用的完整配置上游项目也提供了一份示例 ini[counts] # files that took most time to parse fileParse 20 # files that took most time to generate code for fileCodegen 20 # functions that took most time to generate code for function 30 # header files that were most expensive to include header 1000 # for each expensive header, this many include paths to it are shown headerChain 10 # templates that took longest to instantiate template 50 # Minimum times (in ms) for things to be recorded into trace [minTimes] # parse/codegen for a file file 1 [misc] # Maximum length of symbol names printed; longer names will get truncated maxNameLength 270 # Only print root headers in expensive header report, i.e. # only headers that are directly included by at least one source file onlyRootHeaders false各配置项的含义[counts]段控制各榜单展示条数。注意header 1000——头文件榜单几乎不做截断因为间接包含链分析需要尽可能完整的数据headerChain 10表示每个昂贵头文件展示 10 条包含路径[minTimes]段控制记入 trace 的最小时间阈值毫秒file 1意味着只要解析/代码生成超过 1ms 的文件都会被记录[misc]段中maxNameLength 270限制打印的符号名长度超长截断onlyRootHeaders false表示不仅打印被至少一个源文件直接包含的根头文件间接引入的头文件也会出现在榜单中——对于排查wasm.hh、query_processor.hh这类间接包含链保持 false 是合理的。小结从 trace 到优化的完整闭环将文档内容串起来ScyllaDB 的编译时间治理工作流是清理build目录用./configure.py --cflags-ftime-trace或--time-trace/ CMake 的-DScylla_TIME_TRACEON重新生成构建脚本ninja build/dev/scylla收集每个源文件的 JSON traceClangBuildAnalyzer --all build/dev build/dev/clba.bin合并--analyze出报告优先处理模板实例化榜单和最昂贵头文件榜单中的项目减少热门头文件中的模板包含、拆分头文件、审查间接包含链、必要时使用extern template修改后只重跑 ninja ClangBuildAnalyzer 两步得到更新统计由于单次构建时间测量噪声大用du -bc build/dev/**/*.o的目标文件总大小作为构建工作量节省量的稳定代理指标。这套方法的核心洞察在于对 ScyllaDB 这类模板密集型代码库哪个文件慢远不如哪个模板被实例化了多少次、哪个头文件通过多少条间接链被包含来得可操作——而-ftime-trace ClangBuildAnalyzer 恰好回答了后两个问题。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ScyllaDB 编译耗时分析用 ClangBuildAnalyzer 定位拖慢构建的头文件与模板【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbScyllaDB 的构建时间自项目第一天起就是核心痛点——仓库中的 docs/dev/compilation-time-analysis.md 明确指出ScyllaDB 的 issue #1 就是关于构建过慢的。在模板密集型 C 代码Seastar 与 ScyllaDB中模板实例化与代码生成的耗时远超源码解析两个等长的头文件可能一个只增加毫秒级开销、另一个却拖慢整秒。本文基于该官方开发者文档完整讲解如何用 Clang 的-ftime-trace选项配合 ClangBuildAnalyzer 工具测量、聚合、解读编译时间数据从而找到最昂贵的头文件与模板实例化并验证代码修改对构建性能的实际影响。读完本文你将掌握一套可复制的构建性能剖析 → 修改 → 验证的完整工作流。为什么头文件体积不等于构建开销文档首先给出了一个关键认知C 编译器时代编译时间与源码量基本成正比减少不必要的头文件包含是唯一手段。但在现代 C 中模板实例化和代码生成的时间开销比单纯解析高出几个数量级。这意味着优化目标不再是减小头文件而是减少昂贵模板的重复实例化次数以及打断不必要的间接包含链。ScyllaDB 的构建系统正是围绕这一认知设计的。从源码结构看configure.py 中定义了 dev、release、debug、sanitize 等构建模式其中 dev 模式的定位就是optimized for fast build timesconfigure.py它使用-O2、不生成调试信息。而构建脚本在生成 build.ninja 时针对scylla主程序启用了预编译头-fpch-instantiate-templates编译stdafx.hh.pch见 configure.py——这也是为什么模板开销统计仍会暴露问题PCH 无法消除模板在不同编译单元中的重复实例化。安装 ClangBuildAnalyzerClangBuildAnalyzer 是一个开源工具用于聚合所有源文件的-ftime-trace日志判断哪些头文件和模板最拖慢构建。安装步骤git clone https://github.com/aras-p/ClangBuildAnalyzer然后用make -f projects/make/Makefile构建并将产物build/ClangBuildAnalyzer加入 PATH。注意该工具只依赖 Clang 的 trace 输出格式不需要修改 ScyllaDB 仓库本身。开启 -ftime-trace两种官方入口文档给出的标准做法是在 Scylla 工作目录中先清理旧构建目录避免把已删除源文件或无关构建模式的旧.json计入统计rm -r build然后重新运行configure.py生成 build.ninja并追加-ftime-trace到编译命令./configure.py --disable-dpdk --cflags-ftime-trace--cflags参数在 configure.py 中定义为 Extra flags for the C compiler其值最终会进入每个编译模式dev/release 等的lib_cflags并透传给 build.ninja 中所有 C 编译规则。此外仓库还提供了两个更便捷的等价入口可视为同一机制的封装--time-trace参数ninja 后端configure.py 中显式定义了--time-trace开关其帮助文本说明Each .o produces a .json file analyzable with ClangBuildAnalyzer or chrome://tracing。在源码内部当该参数开启时-ftime-trace同样被追加到user_cflagsconfigure.py。因此./configure.py --time-trace与--cflags-ftime-trace效果一致且语义更清晰。CMake 后端若使用./configure.py --use-cmake构建cmake/mode.common.cmake 提供了Scylla_TIME_TRACE选项用法为cmake -DScylla_TIME_TRACEON ...它强制要求 Clang 编译器否则直接FATAL_ERROR并在满足条件时对全部编译添加-ftime-trace。构建并收集每文件的 JSON trace开启 trace 后只需构建单一构建模式的scylla主可执行文件文档以 dev 模式为例ninja build/dev/scylla构建过程中每个被编译的源文件都会在构建目录下生成一个独立的JSON 文件包含该文件的编译耗时分析。例如编译cdc/generation.cc会产生build/dev/cdc/generation.json。这些 JSON 文件采用 Chrome trace 格式可以单独用各种工具查看包括 Google 的 Perfetto UI可通过chrome://tracing加载。但单文件视角回答不了整体最慢的是哪个头文件/模板这个问题——这正是 ClangBuildAnalyzer 的价值所在ClangBuildAnalyzer --all build/dev build/dev/clba.bin ClangBuildAnalyzer --analyze build/dev/clba.bin | less--all把所有.json合并为一个二进制文件clba.bin--analyze则产生人类可读的报告。迭代使用修改代码后的正确复测方法文档给出了四条重要的实操细节直接影响测量正确性首次构建会全量重编。因为-ftime-trace改变了命令行即使之前用 ccache 构建过第一次带 trace 的 ninja 也必须全部重编。并且 ccache 在-ftime-trace启用期间会主动放弃缓存ccache 官方 release notes 中仅说明too hard。改动后只需重跑 ninja 与 ClangBuildAnalyzer 两步。ninja 只重编受影响的源文件这些文件对应的.json会更新ClangBuildAnalyzer 会结合新旧 JSON 生成最新的统计。删除源文件要手动清理残留 JSON。被移除源文件的.json仍留在build/dev/下会向统计中注入错误信息需手动删除该 JSON或删除整个build目录重来。不再需要测量时去掉--cflags-ftime-trace或--time-trace重跑 configure.py 即可恢复普通构建。用 du 估算构建时间收益文档指出了一个实用的替代指标构建时间测量精度不高小幅改进难以直接观测但 ScyllaDB 团队观察到构建时间与产出的目标文件总大小高度相关du -bc build/dev/**/*.o其原理是 C 编译器慢通常因为它生成了巨量代码。因此这条du命令的输出可作为本次修改节省了多少编译工作量的良好估计量——它比墙钟时间更稳定、可重复。解读 ClangBuildAnalyzer 报告六类输出逐段拆解ClangBuildAnalyzer --analyze build/dev/clba.bin的输出由多个榜单组成文档按信息价值从高到低逐一解释。以下以文档中的真实输出为例。1. Files that took longest to parse / codegen这两个段落列出解析前端和代码生成后端最耗时的源文件。文档当时的头号问题是messaging_service.cc**** Files that took longest to parse (compiler frontend): 84164 ms: build/dev/message/messaging_service.o ... **** Files that took longest to codegen (compiler backend): 135417 ms: build/dev/message/messaging_service.o即仅约 1,376 行代码当前仓库中 message/messaging_service.cc 为 1,500 余行与文档描述一致的源文件前后端合计消耗约 4 分钟 CPU 时间。文档诚实地指出这类信息告诉我们哪个文件慢却不解释为什么慢。它的实用价值有限——最多用于把最慢的文件排在并行构建最前面避免 straggler或把大文件进一步拆分。2. Templates that took longest to instantiate最有价值的一节**** Templates that took longest to instantiate: 385738 ms: fmt::detail::vformat_tochar (552 times, avg 698 ms) 197016 ms: boost::basic_regexchar::assign (329 times, avg 598 ms) 195522 ms: ser::deserializeseastar::simple_memory_input_stream (1617 times, av g 120 ms) ...这份榜单上的模板有两个共同特征被很多源文件使用常因为出现在被广泛包含的头文件中且单次实例化极其昂贵上例中vformat_tochar每次实例化高达 0.7 秒。针对它们文档给出三条具体优化路径减少实例化次数——例如避免在热门头文件中包含该模板或减少对该头文件的包含改写模板减少其内部嵌套的其他模板使用extern template显式实例化让模板只实例化一次。对比前一小节可以看到差异的本质单个函数只编译一次再慢也只是常数而模板是乘以包含它的编译单元数量——552 次 × 698ms ≈ 386 秒这就是模板榜单值得优先处理的原因。3. Template sets that took longest to instantiate*** Template sets that took longest to instantiate: 640682 ms: std::unique_ptr$ (31372 times, avg 20 ms) 581171 ms: std::__and_$ (351772 times, avg 1 ms)template set把同一模板族的所有具体化归并统计。文档认为这一节直接可用性较低我们只能寄望其他改动顺带减少std::unique_ptr的实例化次数没有直接可操作的手段。4. Functions that took longest to compile**** Functions that took longest to compile: 2899 ms: cql3_parser::CqlParser::cqlStatement() (build/dev/gen/cql3/CqlParser.cpp) 2144 ms: replica::database::setup_metrics() (replica/database.cc)可以挑个别函数看看为何慢文档举例alternator::stats::stats()这样很短的函数因 Boost options 的宏技巧耗时整秒。但总体上这一节不值得深挖因为每个函数只编译一次优化收益有上限——这与模板被编译数百次的情形形成鲜明对照。5. Function sets that took longest to compile / optimize与上一节类似但针对模板函数可被编译多次*** Function sets that took longest to compile / optimize: 57092 ms: fmt::v9::appender fmt::v9::detail::write_int_noinline$(...) (1071 times, avg 53 ms) 44361 ms: fmt::v9::detail::format_dragon(...) (357 times, avg 124 ms)这一节帮助从函数体角度交叉印证模板榜单——例如 fmt 库的格式化路径在这里和模板实例化榜单中反复出现说明其是构建开销的重灾区。6. 最昂贵头文件文档称最有趣的段落之一1086240 ms: replica/database.hh (included 139 times, avg 7814 ms), included via: 47x: query_processor.hh wasm.hh 46x: direct include 14x: schema_registry.hh 6x: user_function.hh wasm.hh 5x: cql_test_env.hh 4x: column_family.hh ...该段落的信息密度最高包含三层内容总开销replica/database.hh累计 1086 秒当时约占总构建时间 6%被包含 139 次、平均每次约 8 秒包含链统计139 个包含者中只有 46 个是直接包含其余经过wasm.hh、query_processor.hh、schema_registry.hh等头文件间接引入——这些间接包含是否必要正是需要逐一审查的对象优化方向减少database.hh的包含、拆分它、或让它做的事更少。注意头文件开销是高估值文档特别强调1086 秒这个数字是过估计。实际删掉database.hh不会减少 1086 秒编译时间原因是database.hh包含的其他头文件、实例化的其他模板会记账到这个头文件名下——因为它恰好在某个编译单元中最先使用了这些模板。但其他头文件同样会用到它们即使删掉database.hh它们照样会被实例化。文档的结论是不实际动手试一下无法知道真实收益。因此对榜单应该排序参考、实测验证这正是下一节du度量存在的原因。用 ClangBuildAnalyzer.ini 定制报告ClangBuildAnalyzer 的每个榜单默认只展示固定数量的 Top N 条目。文档介绍了ClangBuildAnalyzer.ini配置机制并给出了作者实际使用的完整配置上游项目也提供了一份示例 ini[counts] # files that took most time to parse fileParse 20 # files that took most time to generate code for fileCodegen 20 # functions that took most time to generate code for function 30 # header files that were most expensive to include header 1000 # for each expensive header, this many include paths to it are shown headerChain 10 # templates that took longest to instantiate template 50 # Minimum times (in ms) for things to be recorded into trace [minTimes] # parse/codegen for a file file 1 [misc] # Maximum length of symbol names printed; longer names will get truncated maxNameLength 270 # Only print root headers in expensive header report, i.e. # only headers that are directly included by at least one source file onlyRootHeaders false各配置项的含义[counts]段控制各榜单展示条数。注意header 1000——头文件榜单几乎不做截断因为间接包含链分析需要尽可能完整的数据headerChain 10表示每个昂贵头文件展示 10 条包含路径[minTimes]段控制记入 trace 的最小时间阈值毫秒file 1意味着只要解析/代码生成超过 1ms 的文件都会被记录[misc]段中maxNameLength 270限制打印的符号名长度超长截断onlyRootHeaders false表示不仅打印被至少一个源文件直接包含的根头文件间接引入的头文件也会出现在榜单中——对于排查wasm.hh、query_processor.hh这类间接包含链保持 false 是合理的。小结从 trace 到优化的完整闭环将文档内容串起来ScyllaDB 的编译时间治理工作流是清理build目录用./configure.py --cflags-ftime-trace或--time-trace/ CMake 的-DScylla_TIME_TRACEON重新生成构建脚本ninja build/dev/scylla收集每个源文件的 JSON traceClangBuildAnalyzer --all build/dev build/dev/clba.bin合并--analyze出报告优先处理模板实例化榜单和最昂贵头文件榜单中的项目减少热门头文件中的模板包含、拆分头文件、审查间接包含链、必要时使用extern template修改后只重跑 ninja ClangBuildAnalyzer 两步得到更新统计由于单次构建时间测量噪声大用du -bc build/dev/**/*.o的目标文件总大小作为构建工作量节省量的稳定代理指标。这套方法的核心洞察在于对 ScyllaDB 这类模板密集型代码库哪个文件慢远不如哪个模板被实例化了多少次、哪个头文件通过多少条间接链被包含来得可操作——而-ftime-trace ClangBuildAnalyzer 恰好回答了后两个问题。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
