Kengo's blog

Technical articles about original projects, JVM, Static Analysis and JavaScript.

WIP: Gradleの機能でどこまでビルド性能が改善するのか

Gradleの --parallelJUnit並列実行、Configuration Cacheなどがどの程度ビルド性能を改善するのか、いくつかのOSSで実測してみた。利用した機能の概要は以下オフィシャルサイトを参照のこと。

docs.gradle.org

SonarQubeの事例

バージョン 9.0.1.46107 リリース後の master ブランチで実践。進捗などは以下のIssueで管理している:

github.com

もともとGradle 6.8.2を使っていたが、1,092ものbuild deprecationsが報告されておりGradle 7に直接アップグレードすることができない状態。Gradle 7ではいくつかのTaskのaccessorがLazy ConfigurationのためのAPIで置き換えられており、移行が必要。また依存管理に非推奨となっているcompiledefaultを使っており、implementationruntimeClasspathJava Library Pluginが提供するapiなどへの移行が必要。

最大の難関は com.github.hierynomus.license プラグインcom.github.johnrengelman.shadow プラグインが古く、数多くの警告が出ているというもの。タスクの入出力が不明瞭なためキャッシュも効いていない。またプラグインの最新版がGradle 6をサポートしていないため、これらのアップグレードはGradleの7へのアップグレードと同時に実行する必要があった。

f:id:eller:20211020102235p:plain
手を加える前のBuild scan結果。プラグイン由来の警告が多い。

改善結果

21分半かかっていたフルビルドが16分弱(73.3%)で終わるようになった。

f:id:eller:20211204093213p:plain
中央値で比較して73.3%に短縮

Parallel buildはビルド時間を1分程度短縮する効果があったが、GitHub ActionsのHosted Runnerは2コアしかないためデフォルトでは2並列にしかならない。サブプロジェクトが多いなら --max-workers などの設定でワーカー数を増やす方が良い。

f:id:eller:20211020104306p:plain
4並列でビルドしたときのタイムライン

テストの並列実行は残念ながらビルド性能の改善に繋がらなかった。Parallel buildでCPUを使い切っており性能が出なかったためと思われる。実際サブプロジェクトひとつのテストを実施してみると、テストの並列実行を有効化したほうが性能が出る。サーバが必要なBuild Cacheは試していないが、これを有効化することでフルビルドの必要性が下がるため、テスト並列実行の重要性も上がると期待される。

SpotBugs

実験中。Antから無理やり移したタスクがEclipse plugin周辺で残っているので、まず buildSrc にビルドロジックを移動させるところからやる必要がある。 Eclipse関連の依存をMaven Centralからダウンロードするようにしたいが、以下の課題が未解決。

www.eclipse.org