Arm 性能测试

在较慢的平台上，构建系统的性能差异会更加明显。为了检验这种差异，我们比较了 Meson 和 GNU Autotools 的性能。我们选取了 GLib 软件项目，并使用 Meson 重写了它的构建设置。选择 GLib 是因为它是一个相对较大的 C 代码库，需要大量的底层配置。

Meson 版本的构建系统并不完全等同于原始的 Autotools 版本。它没有执行相同的配置步骤，也没有构建相同的目标。最大的缺失部分是使用 Gettext 的国际化支持。但是，它确实配置了系统，足以构建所有 C 源代码并运行所有单元测试。

所有测量都在运行最新 Ubuntu touch 镜像（2013 年 9 月 9 日更新）的 Nexus 4 智能手机上进行。

测量

我们首先测量的是运行配置步骤所需的时间。

Meson 大概需要 20 秒，而 Autotools 需要 220 秒。这是一种数量级的差异。Autotools 的时间包含 autogen 和 configure。同样需要记住，Meson 并没有执行 Autotools 所做的所有配置步骤。它完成了大约 90% 的步骤，而完成这些步骤所需的时间仅为 10%。

然后我们测量了构建时间。两种系统都使用了两个并行编译进程。

在桌面机器上，基于 Ninja 的构建系统比基于 Make 的构建系统快 10-20%。在这个平台上，差异增至 50%。这种差异可能是由于 Make 的磁盘访问模式效率低下造成的。Ninja 在保持两个核心始终运行方面更出色，这带来了令人印象深刻的性能提升。

接下来我们测量了“空构建”情况。也就是说，构建系统检测到不需要进行任何更改需要多长时间。这是构建系统最重要的指标之一，因为它对代码迭代速度设置了硬性限制。Autotools 需要 14 秒才能确定不需要进行任何工作。Meson（或者更确切地说，Ninja）只需四分之一秒。

一个需要相当长时间的步骤是链接。常见的情况是，您正在开发一个库，并且有数十个小型测试可执行文件链接到它。即使编译步骤很快，重新链接所有测试可执行文件也需要时间。人们通常会使用诸如 make sometest 这样的命令手动编译一个测试应用程序，而不是重建所有内容。

Meson 针对这种情况进行了优化。每当重建库时，Meson 都会检查它导出的 ABI。如果它没有改变，Meson 将跳过所有重新链接步骤，因为它们是不必要的。这种变化带来的差异可以在上面的图表中清楚地看到。在那个测试中，源代码被完全构建，然后文件 glib/gbytes.c 被修改以强制重建基本 glib 共享库。如您所见，Autotools 然后重新链接所有链接到 glib 的测试可执行文件。由于 Meson 可以检测到 ABI 是相同的，因此它可以跳过这些步骤。最终结果是 Meson 在这种非常常见的用例中快了近一百倍。

结论

与 Java 等语言相比，C 和 C++ 的主要缺点之一是编译时间过长。但是，至少部分原因可能是构建工具本身，而不是语言本身或它们的编译器。选择合适的工具可以使 C 和 C++ 编译几乎达到即时重建。这对程序员的生产力有直接影响。