Gradle vs Bazel构建的性能

Question

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

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

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

Answer 1

Dropbox ran some benchmarks最近：

请注意，对于Bazel，无缓存情况下的干净构建速度要慢得多，而增量构建情况下则要快得多。

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

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

这些操作的某些可执行文件也可能具有较高的启动成本（例如javac），这些成本在多次重新启动这些过程时会加起来。 Bazel具有一种称为“持久性工作程序”的机制，其中各个操作的可执行过程（例如javac，tsc，scalac或ghc的编译器包装）可以在操作之间持久化执行，节省启动时间并在进程级别启用更低级别的缓存。

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

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

对于无操作构建案例，依赖关系图也进行了高度优化。如果您的项目没有任何变化，那么Bazel应该花最少的时间来找出没有变化的东西，因此无需执行任何操作。

还可以通过远程缓存，远程执行或不运行相对罕见的bazel clean来缓解缓慢的干净构建的缺点，因为构建的目的是封闭，确定性和consistent。对于Bazel，具有100％远程高速缓存命中率的内部版本很常见。

Answer 2

好的，我已经将包含约100_000个Java位置的封闭源项目迁移到了bazel。

等级 5.6.3 与淡褐色 1.0.1

我无法衡量整洁的构建，因为我不确定如何将下载依赖项步骤与编译步骤分开，并且无论如何我都不会为此打扰。就像我说过的那样，我的兴趣在于开发人员的工作效率，因此也涉及增量构建。

我在BUILD中使用了以下内容来制作淡褐色，所以我没有使用最细致的方法，因为我认为这实际上是无法维护的，除了拥有很多人的大公司以外，其他任何人都可以使用。而且无论如何，我都看到我需要手动执行此操作以提高构建速度的事实，这是事实的缺点。

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

增量构建，其中包含一个或两个更改的文件。

等级- 1s ，淡褐色- 4.227s

我尝试了多次，每次gradle都明显更快。当更改了一个或两个以上文件时，我还没有测试增量构建，也许在这种情况下，bazel将比gradle相同或更快。

无操作版本 gradle- 700毫秒，浅色- 0.090ms

因此，速度明智的gradle似乎是开发人员生产率的赢家。 Bazel在gradle中有更多安全默认值（默认情况下容易出错），您必须自己启用它，但是恕我直言，gradle的灵活性远胜于bazel的更安全默认值。