Bazel 运行很慢
Bazel runs very slowly
我有一个相对简单的 Bazel 项目，其中包含以下内容：
- 2 个原型文件（B.proto 取决于 A.proto）
- Go/C++ 从这些支持 grpc 的原始文件生成的库（使用从 pubref/rules_protobuf 导入的 grpc/protobuf 规则）
- Server/client 个针对这些用 C++ 和 Go 编写的原型的应用程序。
当我第一次 运行 bazel 时，执行它需要很多时间。它编译grpc，protobuf等，这是有道理的。
然而，当我立即 运行 再次编译时，即使在增量情况下，我的构建也需要大约 80 秒。对于一个如此简单的项目，我本来期望更快的性能——尤其是因为据说速度是 Bazel 的主要优势。
据我所知，我的 bazel 构建的性能非常快，直到我合并 grpc/protos。
以下是 bazel 的分析器报告的一些信息。我在探查器输出中看不到任何确凿证据。
一个可能的区别是我在 macbook 上托管的 ubuntu docker 容器上构建 运行。轻量级 hyperkit VM 上的 macos docker 实现 运行s。所以这不是本机构建。但我还是没想到会这么慢！
阶段摘要信息
- 启动阶段总时间 101 毫秒 0.12%
- 初始阶段总时间 11.560 秒 13.67%
- 总加载阶段时间 282 ms 0.33%
- 总分析阶段时间 15.2 ms 0.02%
- 总准备阶段时间 1.002 s 1.19%
- 总执行阶段时间 71.549 s 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% 2109 毫秒
- VFS_READ 0.01% 4 28.7 毫秒
执行阶段信息
- 总准备时间 1.002 秒
- 总执行时间 71.549 秒
- 总完成时间 30.9 毫秒
- 创建动作依赖图 0.00 毫秒
- 实际执行时间71.549秒
- 总时间（跨所有线程）花费在：
- 类型总计数平均值
- 行动 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% 动作 'BazelWorkspaceStatusAction stable-status.txt'
我在 AWS EC2 实例上尝试了相同的构建。那里的增量构建要快得多。所以我假设速度缓慢是由于 VM 内部 运行 导致的一些文件系统问题。
我有一个相对简单的 Bazel 项目，其中包含以下内容：
- 2 个原型文件（B.proto 取决于 A.proto）
- Go/C++ 从这些支持 grpc 的原始文件生成的库（使用从 pubref/rules_protobuf 导入的 grpc/protobuf 规则）
- Server/client 个针对这些用 C++ 和 Go 编写的原型的应用程序。
当我第一次 运行 bazel 时，执行它需要很多时间。它编译grpc，protobuf等，这是有道理的。
然而，当我立即 运行 再次编译时，即使在增量情况下，我的构建也需要大约 80 秒。对于一个如此简单的项目，我本来期望更快的性能——尤其是因为据说速度是 Bazel 的主要优势。
据我所知，我的 bazel 构建的性能非常快，直到我合并 grpc/protos。
以下是 bazel 的分析器报告的一些信息。我在探查器输出中看不到任何确凿证据。
一个可能的区别是我在 macbook 上托管的 ubuntu docker 容器上构建 运行。轻量级 hyperkit VM 上的 macos docker 实现 运行s。所以这不是本机构建。但我还是没想到会这么慢！
阶段摘要信息
- 启动阶段总时间 101 毫秒 0.12%
- 初始阶段总时间 11.560 秒 13.67%
- 总加载阶段时间 282 ms 0.33%
- 总分析阶段时间 15.2 ms 0.02%
- 总准备阶段时间 1.002 s 1.19%
- 总执行阶段时间 71.549 s 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% 2109 毫秒
- VFS_READ 0.01% 4 28.7 毫秒
执行阶段信息
- 总准备时间 1.002 秒
- 总执行时间 71.549 秒
- 总完成时间 30.9 毫秒
- 创建动作依赖图 0.00 毫秒
- 实际执行时间71.549秒
- 总时间（跨所有线程）花费在：
- 类型总计数平均值
- 行动 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% 动作 'BazelWorkspaceStatusAction stable-status.txt'
我在 AWS EC2 实例上尝试了相同的构建。那里的增量构建要快得多。所以我假设速度缓慢是由于 VM 内部 运行 导致的一些文件系统问题。