Bazel项目中aquery性能回归问题的技术分析

在Bazel构建工具的最新版本7.5.0中，用户报告了一个关于aquery命令的性能回归问题。这个问题出现在从7.1.1版本升级后，某些查询操作的执行时间显著增加，达到了原先的4倍左右。

问题背景

aquery（Action Query）是Bazel提供的一个功能，用于查询构建过程中生成的动作信息。用户在使用特定模式的查询时发现性能明显下降，特别是在执行类似以下形式的查询时：

let x = kind("release_group", ${TARGETS}) in $x except attr("tags", ".*\b(disabled|...)\b.*", $x)

这种查询用于筛选特定类型的构建目标，并排除带有某些标签的目标。在7.1.1版本中，这类查询大约需要1分钟完成，而在7.5.0版本中则可能需要4分钟甚至更长时间。

问题根源

经过调查，这个问题与Bazel的一个内部变更有关。该变更使aquery需要执行更多工作来实现与cquery相同的功能。虽然这是有意为之的设计决策（Working As Intended），但确实导致了性能上的代价。

技术解决方案

开发团队提出了两个潜在的改进方向：

1. 为aquery添加config函数支持：这将允许用户更精确地控制查询的范围和深度，可能通过指定配置参数来优化查询性能。

2. 引入"toplevel"配置选项：这个特殊配置将只返回顶层的配置目标（可能经过测试修剪），让用户能够选择性地恢复到旧版更快的查询行为。

特别是"toplevel"配置选项，它将同时支持测试修剪和未修剪的变体，为用户提供更灵活的查询控制，同时避免让用户过多考虑测试修剪的细节。

对用户的影响和建议

对于遇到此问题的用户，建议：

1. 暂时可以考虑继续使用7.1.1版本，如果性能是关键因素
2. 关注后续版本中可能加入的config函数和"toplevel"配置支持
3. 考虑重构查询逻辑，可能通过更精确的目标指定来减少查询范围

Bazel团队将此视为功能增强带来的必要性能权衡，而非纯粹的缺陷。未来版本可能会提供更多选项让用户在功能和性能之间做出选择。

总结

Bazel作为一个复杂的构建系统，其查询功能的演进需要在功能完整性和性能之间找到平衡。这次aquery的性能变化反映了这种权衡，而团队提出的解决方案既保持了功能完整性，又为性能敏感场景提供了潜在的优化路径。用户可以根据自己的使用场景选择合适的版本或等待这些优化功能的正式发布。