我有一个相对简单的 Bazel 项目，它具有以下内容:
2 个 proto 文件(B.proto 依赖于 A.proto)从这些具有 grpc 支持的 proto 文件生成的 Go/C++ 库(使用从 pubref/rules_protobuf 导入的 grpc/protobuf 规则)针对这些用 C++ 和 Go 编写的 protos 的服务器/客户端应用程序。 当我第一次运行 bazel 时，它需要很多时间来执行。它编译了 grpc、protobuf 等，这是有道理的。
但是，当我立即再次运行编译时，即使在增量情况下，我的构建也需要大约 80 秒。对于一个如此简单的项目，我本来期望性能会更快——尤其是因为据说速度是 Bazel 的主要优势。
据我所知，在我合并 grpc/protos 之前，我的 bazel 构建的性能非常快。
这是 bazel 的分析器报告的一些信息。我无法在分析器输出中看到任何冒烟的枪。
一个可能的区别是我的构建在 macbook 上托管的 ubuntu docker 容器上运行。 macos docker 实现在轻量级 hyperkit VM 上运行。所以这不是原生构建。但我还是没想到事情会这么慢!
阶段概要信息
总启动阶段时间 101 毫秒 0.12% 初始阶段总时间 11.560 秒 13.67% 总加载阶段时间 282 毫秒 0.33% 总分析阶段时间 15.2 ms 0.02% 总准备阶段时间 1.002 秒 1.19% 总执行阶段时间 71.549 秒 84.63% 总完成阶段时间 30.9 毫秒 0.04% 总运行时间 84.540 秒 100.00% 初始化阶段信息
总初始化时间 11.560 秒 总时间(跨所有线程)花费在:
类型 总计数平均值 VFS_STAT 88.18% 12223 166 毫秒 VFS_DIR 10.49% 785 307 毫秒 VFS_READLINK 0.81% 221 84.4 毫秒 VFS_OPEN 0.01% 2 109 毫秒 VFS_READ 0.01% 4 28.7 毫秒 执行阶段信息
总准备时间 1.002 秒 总执行时间 71.549 秒 总完成时间 30.9 毫秒 Action 依赖映射创建 0.00 毫秒 实际执行时间 71.549 秒 总时间(跨所有线程)花费在:
类型 总计数平均值 Action 0.00% 1 2.09 毫秒 ACTION_CHECK 0.00% 1 0.71 毫秒 ACTION_EXECUTE 0.00% 1 1.53 毫秒 信息 0.00% 1 0.00 毫秒 VFS_STAT 39.71% 1803 26.3 毫秒 VFS_DIR 0.02% 2 14.0 毫秒 VFS_READLINK 0.36% 18 23.9 毫秒 VFS_MD5 0.00% 1 1.45 毫秒 VFS_DELETE 0.00% 1 1.44 毫秒 VFS_OPEN 0.02% 5 4.30 毫秒 VFS_READ 0.00% 4 0.48 毫秒 VFS_WRITE 0.00% 2 0.32 毫秒 SKYFRAME_EVAL 0.03% 1 31.0 毫秒 SKYFUNCTION 0.02% 5 5.83 毫秒 关键路径(25.7 毫秒): Id 分时说明 15078 25.7 毫秒 100.00% Action “BazelWorkspaceStatusAction stable-status.txt”
我在 AWS EC2 实例上尝试了相同的构建。在那里增量构建要快得多。所以我假设速度缓慢是由于在 VM 内部运行导致的一些文件系统问题。