kledgeb UbuntuやLinuxの最新情報を紹介

Snapアプリケーションの起動時間短縮

Snapパッケージで提供されるアプリケーションには、deb/rpmパッケージで提供されるアプリケーションよりも起動に時間がかかる課題があります。



「snapd 2.36.2」ではこの課題に対し改良が行われ、従来よりもアプリの起動時間が大幅に短縮されました。
2倍から6倍程度の起動時間の短縮に期待できます。

起動時間の課題

まずは改善前の状況です。
起動時間の比較のために使用されたアプリは「Visual Studio Code」です。
「Visual Studio Code」インストール後「Visual Studio Code」を起動し、起動にかかる時間が計測されました。

テスト1(Ubuntu)

「Ubuntu」上でのテストでは、以下のハードウェアが使用されました。

項目 内容
CPU 6-core/12-thread Xeon CPU
メモリー 64GB
ストレージ 2TB 970 EVO NVMe SSD
GPU Nvidia Quadro P2000

計測結果は以下の通りです。

項目 Ubuntu 16.04 Ubuntu 18.04.1 Ubuntu 18.10
snap 2.35.5 2.35.5 2.35.5
snapd 2.35.5 2.35.5 2.35.5
series 16 16 16
kernel 4.15.0-38-generic 4.15.0-39-generic 4.18.0-10-generic
VSCode(deb) 20.3秒 8.0秒 15.3秒
VSCode(Snap) 32.8秒 127.8秒 119.9秒

アプリの起動時間に大きな差が見て取れます。

テスト2(Ubuntu以外)

「Ubuntu」以外のディストリビューション上でのテストでは、以下のハードウェアが使用されました。

項目 内容
CPU 4-core i3 CPU
メモリー 4GB
ストレージ 1TB 5,400rpm HDD
GPU Intel(R) HD 440 graphics

計測結果は以下の通りです。

項目 Fedora 29 Workstation Kubuntu 18.10
snap 2.36-1.fc29 2.36.1
snapd 2.36-1.fc29 2.36.1
series 16 16
kernel 4.19.3-300.fc29.x86_64 4.18.0-11-generic
VSCode(deb/rpm) 28.5秒 22.3秒
VSCode(Snap) 57.7秒 79.5秒

こちらでも差が出ていますが、「Ubuntu」上でのテストほどの差ではありません。

ハードウェアの性能差とその影響

テスト1ではテスト2よりも圧倒的に高性能なハードウェアを使用しています。
にもかかわらずアプリの起動時間を見ると、高性能なハードウェアを使用しているテスト1の方がアプリの起動に大きな差が出ています。
これはハードウェアの性能差が与える影響よりも、Snapの仕組みそのものにボトルネックの原因があることを示しています。

そこでアプリ起動時のプロファイリングが行われ、その結果アプリ初回起動時に行われるフォントキャッシュの生成処理に課題が絞り込まれました。

フォントキャッシュ

GUIデスクトップアプリケーションは通常、システム上で利用可能なフォントを調べるため「fontconfig」ライブラリーを使用します。
この処理はアプリの起動時に行われます。

「fontconfig」はパフォーマンスを改良するため、フォント情報をキャッシュしたキャッシュファイルを使用します。
キャッシュファイルは「fontconfig」に付属する「fc-cache」ユーティリティーによって構築されます。

もしフォントキャッシュが存在していない場合や、あるいは何かしらの理由でフォントキャッシュにアクセスできない場合は、フォントキャッシュの生成処理が実行されます。
このフォントキャッシュの生成処理は、特に大量のフォントがインストールされたシステムでは、処理に時間がかかる可能性があります。

この処理が行われている間、処理が完了するまでGUIアプリが画面上に表示されないケースがあり、この待ち時間はユーザーにアプリの起動が遅いと感じさせる結果になるでしょう。

fontconfigキャッシュの改良

フォントキャッシュの生成処理によりアプリの起動が遅くなっている課題を解決するため、「snap 2.36.2」では「core」に「fc-cache-v6」と「fc-cache-v7」バイナリーを含めるように修正されました。
またこれらのバイナリーは、Snapソフトウェアをインストールした時に自動的にフォントキャッシュを生成するために利用されます。

アプリの起動時に行われていたフォントキャッシュ生成処理をアプリのインストール時に行うことで、ユーザーが感じていたアプリの起動時間の遅さを解消することができます。

しかしそれでも尚、 Snap版アプリの方が起動に時間がかかる状況がありますが、この改善によりユーザーが感じる遅さの許容範囲に余裕を与えることができます。

改良後のテスト

本改良を加えたSnapを利用し、上記と同じテスト環境で再度テストが行われました。

テスト1(Ubuntu)

テスト1ではアプリの起動時間が6倍程度改善されています。
例えば「Ubuntu 18.10」環境では、以下の結果が得られています。

項目 Ubuntu 18.10
snap 2.36.2
snapd 2.36.2
VSCode(deb/rpm) 15.3秒
VSCode(Snap) 22.9秒

テスト2(Ubuntu以外)

同様にテスト2では「Fedora 29 Workstation」での起動時間が半分近く削減され、「Kubuntu 18.10」では3倍以上削減されています。

項目 Fedora 29 Workstation Kubuntu 18.10
snap 2.37.4-2.fc29 2.37.4+18.10
snapd 2.37.4-2.fc29 2.37.4+18.10
VSCode(deb/rpm) 21.2秒 17.2秒
VSCode(Snap) 32.0秒 22.6秒

最終的な差

今回の改良を加えたSnapのテスト結果を比較すると、Snap版「Visual Studio Code」はdeb/rpm版「Visual Studio Code」よりも4秒から11秒程度起動に余計に時間がかかる結果となりました。
平均で6.7秒です。

今回の改良によりフォントキャッシュの生成処理がアプリの起動時間に影響を及ぼすことはなくなりました。
また開発チームはパッケージフォーマットの違いやプラットフォーム固有の違いによる影響の調査に焦点をあてられるようになりました。

アプリのコールドスタート

開発チームはアプリのコールドスタート時(初回起動時)、2,3秒余計に時間がかかることをすでに把握しています。

例えばSnap版「Visual Studio Code」では、およそ80の埋め込まれたライブラリーの読み込みを必要とします。
この結果約9,700ものI/O操作が行われます。
一方埋め込まれたライブラリーを使用しないdeb版「Visual Studio Code」では、約4,500ほどのI/O操作で済みます。

一般的にライブラリーを同梱する手法は、相応のコストをもたらします。
しかし「gnome-3-* content」のように共通のSnapを通じてライブラリーを共有する方法を利用すれば、このコストを軽減することができます。
関連コンテンツ
同一カテゴリーの記事
コメント
オプション