Arm パフォーマンステスト

ビルドシステムのパフォーマンスの差は、低速のプラットフォームでより顕著になります。この違いを調べるために、Meson と GNU Autotools のパフォーマンスを比較しました。GLib ソフトウェアプロジェクトを取り、そのビルド設定を Meson で書き直しました。GLib は、低レベルの構成を数多く必要とする、比較的大きな C コードベースであるため、選択されました。

Meson バージョンのビルドシステムは、元の Autotools と完全に同等ではありません。同じ構成ステップをすべて実行するわけでも、同じターゲットをすべてビルドするわけでもありません。最大の不足点は、Gettext による多言語化のサポートです。ただし、すべての C ソースをビルドし、すべてのユニットテストを実行するには十分な構成を行います。

すべての測定は、最新の Ubuntu タッチイメージ（2013 年 9 月 9 日に更新）を実行している Nexus 4 スマートフォンで行われました。

測定

最初に測定したのは、構成ステップの実行にかかる時間です。

Meson は約 20 秒かかりますが、Autotools は 220 かかります。これは 1 桁違います。Autotools の時間は autogen と configure の両方を含みます。Meson が Autotools が行うすべての構成ステップを実行するわけではないことに注意してください。約 90% を実行しますが、実行にかかる時間はわずか 10% です。

次に、ビルド時間を測定しました。両方のシステムで、2 つの並列コンパイルプロセスが使用されました。

デスクトップマシンでは、Ninja ベースのビルドシステムは Make ベースよりも 10 ～ 20% 高速です。このプラットフォームでは、その差が 50% まで広がります。この差はおそらく、Make の非効率なディスクアクセスパターンが原因です。Ninja は、両方のコアを常に稼働させるのが得意であり、これによりパフォーマンスが大幅に向上します。

次に、「空のビルド」のケースを測定しました。つまり、ビルドシステムが変更を行う必要がないことを検出するのにどのくらい時間がかかるかということです。これはビルドシステムの最も重要な指標の 1 つです。コードを反復処理できる速度に厳しい制限が加わるからです。Autotools は、作業を行う必要がないことを判断するのに 14 秒かかります。Meson（つまり、Ninja）はわずか 0.25 秒かかります。

かなり時間がかかるステップの 1 つはリンクです。一般的なケースは、ライブラリに取り組んでいるとき、そのライブラリにリンクする数十個の小さなテスト実行可能ファイルがある場合です。コンパイルステップが速くても、テスト実行可能ファイルのすべてを再リンクするには時間がかかります。make sometest などのコマンドで手動で 1 つのテストアプリケーションのみをコンパイルし、すべてを再構築するのではなく、それを使用することが一般的です。

Meson にはこのケースに最適化があります。ライブラリが再構築されるたびに、Meson はエクスポートされる ABI を検査します。変更がない場合は、Meson はすべての再リンク手順が不要であることをスキップします。この違いは、上記のチャートで明確に見ることができます。そのテストでは、ソースが完全に構築され、ファイル glib/gbytes.c に触れて、基本 glib 共有ライブラリの再構築を強制しました。ご覧のとおり、Autotools は glib とリンクするすべてのテスト実行可能ファイルを再リンクします。Meson は ABI が同じであることを検出できるため、これらの手順をスキップできます。この非常に一般的な使用例では、最終的に Meson がほぼ 100 倍高速になります。

結論

C と C++ の主な欠点の 1 つは、Java などの言語と比較するとコンパイル時間が長いことです。しかし、非難の少なくとも一部は、言語自体やコンパイラではなく、使用されるビルドツールに見出すことができます。適切なツールを選択すると、C および C++ のコンパイルを瞬時の再構築に非常に近づけることができます。これはプログラマーの生産性に直接影響します。