Gradle vs Bazel构建的性能

Question

因此，现在每个人都在谈论bazel，但是向其迁移并不是自动的（从maven迁移时，gradle在这方面更好）。因此，我不想花时间将任何存储库手动转换为该存储库。

但是我找不到有关gradle（5.6>）和bazel（1.0）的最新版本之间的构建速度差异的任何信息。

任何人都可以分享链接或他自己的经历吗？我最感兴趣的是增量构建，其中仅更改了几个文件。

Answer 1

Dropbox 最近运行了一些基准测试：

请注意，对于Bazel，没有缓存方案的干净构建速度要慢得多，而增量构建方案的速度要快得多。

Bazel构建单元的粒度往往比Gradle的粒度小。看到java_library目标只有一个源文件是很常见的。这些构建单元（也称为目标）中的命令行操作被单独缓存（本地或远程）并组合在一起以构建java_binary。

对于许多小型构建单元，通常会有更多的操作要执行，因此会有更多的磁盘I / O和计算，从而导致较慢的初始干净构建时间。

这些动作的某些可执行文件也可能具有较高的启动成本（例如javac），这在这些进程多次重新启动时加起来。巴泽尔有一个称为持久性工作者的机制，其中对个人行为的可执行程序（如编译器包装器javac，tsc，scalac或ghc）可以在动作执行持久化，节省启动时间，并允许在进程级缓存甚至更低的水平。

另一方面，Bazel的小型构建单元可实现高度增量的构建和快速的迭代开发，如上图所示。

小型构建单元还使Bazel能够形成具有高度并行性的依赖图。通过远程执行，您可以并行运行100到1000个小型构建操作。

依赖图也针对无操作构建案例进行了高度优化。如果您的项目没有任何变化，那么Bazel应该花尽可能少的时间来确定没有变化，因此无需执行任何操作。

缓慢清理构建的缺点也可以通过远程缓存，远程执行或不运行相对罕见的漏洞来缓解，bazel clean因为构建的目的是密封，确定性和一致的。Bazel常见具有100％远程高速缓存命中率的构建。

Answer 2

好的，我已经将包含 ~100_000 loc java 的闭源项目迁移到了 bazel。

Gradle 5.6.3与 bazel 1.0.1

正如我所说，我的兴趣在于开发人员的生产力，因此也在于增量构建。

我在 bazel 的 BUILD 中使用了以下内容，所以我没有使用最精细的方法，因为我认为它不是真正可维护的，而且除了拥有大量 devops 的大公司之外，任何人都可以使用它。无论如何，我发现我需要手动执行此操作以提高构建速度，这是 bazel 的缺点。

java_binary(
    srcs = glob(["src/main/java/**/*.java"]),
    resources = glob(["src/main/resources/**"]),
    ...
)

使用一两个更改的文件进行增量构建。

gradle - 1s，bazel - 4.227s

我已经尝试过多次，每次 gradle 都明显更快。我还没有测试过当超过一两个文件被更改时的增量构建，也许在这种情况下 bazel 会与 gradle 相同或更快。

无操作构建 gradle - 700ms， bazel - 0.090ms

因此，速度方面的 gradle 似乎是开发人员生产力的赢家。Bazel 在 gradle 中有更安全的默认设置（默认情况下容易出错），你必须自己启用它，但恕我直言，gradle 的灵活性胜过 bazel 更安全的默认设置。