构建优化

原文：Why is my Bazel build so slow? 作者：Maggie Lou · 原文署名日期为 2024-04-02。 译注：文中的“我们”指原作者或 BuildBuddy 团队。所译网页已包含 Bazel 8.7、9.1 等后续版本的补充说明，使用 flags 时请核对自己的 Bazel 版本。Bazel 专有名词、命令和代码保持英文；原文几处参数及缓存行为说明的修正见脚注。 Bazel 承诺的是快速构建。可构建还是很慢，该怎么办？去骂当初说服公司迁移到 Bazel 的开发者吗？当然不会！你肯定不会这么做，对吧？🙂 BuildBuddy 可以帮忙。Bazel 提供了大量排查构建耗时的信息，难的是知道该从哪里看起。 也许你连续运行了两次构建，本以为第二次会命中缓存，结果却依然很慢。也许你只运行了一次构建，想弄清时间究竟花在哪里。下面介绍几个排查起点，并结合我们自己的慢构建案例说明。 本文会多次用到 BuildBuddy UI。即使不用它，大部分步骤也能完成，只是需要自己从 Build Event Stream 中查找、解析信息，工作量会大一些。如果你还没有使用 BuildBuddy，可以给构建添加以下 flags，将 Build Events 免费发送到我们的服务器。完整设置步骤见文档。 --bes_results_url=https://app.buildbuddy.io/invocation/ --bes_backend=grpcs://remote.buildbuddy.io 添加后，构建日志中会出现类似 Streaming build results to: https://app.buildbuddy.io/invocation/XXX 的一行。打开这个链接，就能使用下文介绍的许多功能。 1）我使用了正确的 flags 吗？ ⭐ Bazel 的配置选项很多，排查时可以先确认本次构建究竟应用了哪些 flags。下面这些 flags 值得检查：它们可能需要添加，也可能已经设置好了。 --nolegacy_important_outputs 去掉重复的文件引用，减少上传的 Build Event Stream 数据量。 --remote_build_event_upload=minimal 原文将它概括为不向缓存上传标记为 no-cache 的 blob，从而减少网络流量。具体的 BEP 上传范围见译注。1 --remote_download_outputs 限制从缓存下载中间构建 artifacts，减少网络流量。这个 flag 需要指定取值，并非只写名称就会生效。2 --experimental_remote_cache_async 在后台进行缓存 I/O，改善 remote cache 性能。 --noremote_upload_local_results 不向 remote cache 上传本地执行的 action 输出，减少上传量。这会降低后续构建的 cache hit rate；但上传速度受限时，例如网络连接较差，可能值得这样取舍。 --remote_cache_compression 压缩缓存中的 blob，提高 remote cache 吞吐量。 --experimental_remote_cache_chunking remote cache 支持该功能时，以 content-defined chunks 上传、下载大型输出，提高吞吐量。该功能适用于 Bazel 8.7 和 9.1+。 --digest_function=BLAKE3 使用更快的哈希算法，改善大文件的 digest 计算性能。该功能适用于 Bazel 6.4+。 --jobs 允许更多 actions 并行执行，提高执行吞吐量。我们建议从 --jobs=50 开始，再逐步调高。 如果希望每次构建都默认使用这些 flags，可以把它们写进 .bazelrc 文件。我们会把 .bazelrc 提交到 Git，让所有开发者使用统一的构建选项。 ...