このトピックでは、Qt Quick Ultralite アプリケーションのパフォーマンス指標およびメモリ使用量情報を取得する方法について解説します。

Qt Quick Ultraliteのパフォーマンスログ

Qt Quick Ultraliteでは、次のような重要なパフォーマンス指標を収集できます。

• CPUのアイドル時間、
• スタックおよびヒープの使用状況、
• フレームレート、
• キャッシュの使用状況、
• レンダリングに費やされた時間に関する有用な情報、
• およびテキストのレイアウト。

これらのログはボードのシリアルポートを介して出力され、ホストマシンのシリアルターミナルを使用して確認できます。パフォーマンスログを有効にして表示するには：

• パフォーマンスメトリクスを収集するには、Qt Quick Ultralite Coreライブラリを、CMakeオプション「QUL_ENABLE_PERFORMANCE_LOGGING 」を有効にしてビルドする必要があります。Qt for MCUs 2.6以降、これは同梱ライブラリのデフォルト設定となっています。
• シリアルコンソール経由でのパフォーマンスロギング出力も有効にするには、QUL_ENABLE_PERFORMANCE_CONSOLE_OUTPUT というCMakeオプションを有効にし、Qt Quick Ultralite Coreライブラリを再ビルドしてください。
• CPU使用率を確認するには、対応しているプラットフォームにおいて、Qt Quick のUltralite PlatformライブラリをQUL_ENABLE_HARDWARE_PERFORMANCE_LOGGING というCMakeオプションを有効にしてビルドする必要があります。Qt for MCUs 2.6以降、これは同梱ライブラリのデフォルト設定となっています。詳細については、「CPU使用率」を参照してください。
• パフォーマンスログは、シリアル接続を介してホストコンピュータに送信されます。
• お好みのシリアルターミナルを使用して、パフォーマンスログの出力を確認してください。

これらの手順については、以下で詳しく説明します。

パフォーマンスログの有効化

Qt Quick のUltraliteパフォーマンスロギング機能を有効にするには、CMakeオプション「-DQUL_ENABLE_PERFORMANCE_LOGGING=on 」を指定してQt Quick のUltralite Coreライブラリを再ビルドしてください（Qt for MCUs 2.6ではデフォルトで既に有効になっています）。CMakeオプション「-DQUL_ENABLE_PERFORMANCE_CONSOLE_OUTPUT=on 」を前述のオプションと組み合わせて使用することで、ロギング出力をシリアルコンソールに転送することができます。

パフォーマンスロギングが有効になっている場合、QulPerf というQMLタイプを使用して、メトリクスをUI上に直接表示することができます。

パフォーマンスログの表示

minicom、gtkterm、PuTTY、hyperterm などのシリアル端末を使用して、パフォーマンスロギングが有効な状態でビルドされたアプリケーションを実行しているデバイスに接続します。

デバイスがホストデバイスにUSB経由で接続された際に、仮想COMポートを使用したシリアルポートを提供していることを前提として、パフォーマンスログを表示する手順は以下の通りです。

Linux

Linux では、ターゲットデバイスがホストマシンに接続された際に、/dev/ttyACM* または/dev/ttyUSB* のどのポートが表示されるかを確認してください。minicom を使用している場合は、次のコマンドを使用してデバイスに接続してください:

minicom -D /dev/ttyACM2

Infineon TRAVEO T2G などの一部のボードでは、ログ出力に改行を明示的に追加する必要がある場合があります。minicom ターミナルでは、Ctrl+'a' を押してから 'u' キーを押すことで、受信テキストに改行を追加できます。

Windows

Windows で PuTTY ターミナルを使用してパフォーマンスログを表示する方法は以下の通りです。まず、ターゲットデバイスが接続されたときに「デバイスマネージャー」にどのデバイスが表示されるかを確認してください：

それに応じて、PuTTYを次のように設定します：

• シリアル接続タイプ、
• デバイスマネージャーで識別されたシリアルライン、
• および通信速度を115200に設定します。

また、対象デバイスに適したボーレートを確認し、それに応じて速度を調整することも可能です。

これで、QML アプリケーションからのコンソールログおよびパフォーマンスログの出力が表示されるはずです。

ログの例

以下は、QUL_ENABLE_PERFORMANCE_CONSOLE_OUTPUT を有効にした場合のパフォーマンスロギング機能による出力例です：

Memory usage:
Heap: 61596/67820 (in-use/total)
Stack: 13132 (peak)
Resource cache for allocation type 1: 1110016 bytes used out of 2211840 bytes max, 4 entries (block size: 1024)
Text cache: 20480 bytes used out of 24576 bytes max, 7 entries (block size: 1024)
Glyph layout cache: 23552 bytes used out of 24064 bytes max, 46 entries (block size: 512)
Monotype spark cache: 35056 bytes used out of 200000 bytes max
Monotype spark cache priming: 1128 entries copied in 14 ms
refresh intervals: 1: 7, 2: 18, 3: 6,
10 fps (last 31 frames)
animation tick: 0.1% (avg: 0.1 ms, worst: 0 ms)
flush: 4.9% (avg: 5.0 ms, worst: 6 ms)
repaint: 7.2% (avg: 7.3 ms, worst: 42 ms)
  prepare: 0.5% (avg: 0.5 ms, worst: 1 ms)
  region compute: 0.0% (avg: 0.0 ms, worst: 0 ms)
  paint: 6.5% (avg: 6.6 ms, worst: 41 ms)
    spark scale change: 0.1% (avg: 0.1 ms, worst: 3 ms)
    spark glyph retrieval: 0.1% (avg: 0.1 ms, worst: 2 ms)
    text layout: 0.8% (avg: 0.8 ms, worst: 14 ms)
    text blend: 0.8% (avg: 0.8 ms, worst: 4 ms)
    rect blend: 1.8% (avg: 1.8 ms, worst: 9 ms)
    rect fill: 1.0% (avg: 1.1 ms, worst: 3 ms)
    image blend: 1.3% (avg: 1.3 ms, worst: 9 ms)
      alpha w/color: 0.3% (avg: 0.3 ms, worst: 0 ms)
      alpha: 0.9% (avg: 0.9 ms, worst: 8 ms)
      opaque: 0.1% (avg: 0.1 ms, worst: 1 ms)

最初の3行は、アプリケーションのヒープおよびスタックの使用状況を示しています。

続いて、リソース（イメージ）、テキスト、グリフレイアウト、およびMonotype Sparkフォントエンジンの各キャッシュについて、現在の使用量と総容量がそれぞれ表示されます。

QUL_FONT_CACHE_PRIMING が有効になっている場合、さらに1行追加され、最初のフレームの前に Spark キャッシュにコピーされたプリベイク済みグリフエントリの数と、その処理に要した時間が報告されます。これを参考にして、ご自身のボード上で宣言されたfont.unicodeCoverage のコストを見積もってください。 コストは、プリミングデータの保存場所とそのメモリの速度、クロック速度、およびプラットフォームのグリフ位置合わせ要件によって各エントリがそのままコピーされるのではなくパディングされる必要があるかどうかに依存するため、あるボードで測定された数値は別のボードについてはほとんど参考になりません。

最初の3つのキャッシュは固定サイズのブロックアロケータを使用しており、ブロックサイズもログ出力に表示されます。これらのキャッシュのメモリ割り当ては常にブロックサイズの倍数で行われるため、ブロックサイズが大きいとメモリの無駄が増える可能性がありますが、空きブロックをスキャンする際の割り当てオーバーヘッドは軽減されます。

次に、1、2、または3回のリフレッシュ（vsync）間隔を要してレンダリングされたフレーム数に関する情報です。60フレーム/秒で一貫してレンダリングを行うためには、すべてのフレームが1回のリフレッシュ間隔内にレンダリングを完了する必要があります。

「10 fps」という行（直近31フレーム）は、これらの統計が直近31フレーム分のものであり、平均が1秒あたり10フレームであることを意味します。

最後に、Qt Quick Ultralite レンダリングパイプラインの各部分に関するタイミング統計があります。「avg」値は特定のフレームに費やされた平均時間を表し、「worst」値は単一のフレームに費やされた最長時間を表します。ログに表示される可能性のあるさまざまなタイミング統計の概要は以下の通りです：

CPU使用率

Qt Quick UltraliteをサポートするプラットフォームでそのCPU使用率を確認するには、CMakeオプション「-DQUL_ENABLE_HARDWARE_PERFORMANCE_LOGGING=on 」を指定して、Qt Quick Ultraliteプラットフォームライブラリを再ビルドしてください。

CPU負荷情報は、シリアル出力に次のように表示されます：

CPU Load: 44.47

この例では、CPU負荷が44.47 %であることを示しています。CPUは、時間の半分をわずかに超える期間、アイドル状態でした。

メモリ使用量

フットプリント情報は、アプリケーションに必要なRAMやフラッシュメモリの容量を決定する際や、バイナリのサイズを縮小しようとする際に重要です。Qt Quick Ultraliteアプリケーションのフットプリント情報は、サポートされているツールチェーンが提供するツールや「Resource cache」アプリケーションを使用して取得できます。

ツール

ツールチェーン固有のツールを使用すると、アプリケーションバイナリによるメモリ消費量を特定できます。これらのツールは、使用するフラグが異なり、出力結果も異なります。以下のサブセクションでは、Qt for MCUs でサポートされている 3 つのツールチェーン（ARM GCC、IAR、GHS）が提供するこれらのツールについて説明します。

ARM GCC

ARM GCC には、アプリケーションのメモリ消費量を測定するために使用できる 2 つの独立したツールが含まれています。それは、size とreadelf です。これらは、ARM GCC のインストールフォルダ内のbin ディレクトリにあります。バイナリ名の先頭にはarm-none-eabi- が付いています。たとえば、size バイナリはarm-none-eabi-size という名前になっています。また、これらは多くの Linux ディストリビューションに含まれているGNU Binutilsパッケージの一部でもあります。

size は、バイナリやアーカイブのセクションサイズを一覧表示するユーティリティです。セクションサイズは、さまざまな形式で表示できます：

• SystemV 形式 (-A または--format=sysv) この形式では、すべてのセクションとそのサイズが一覧として表示されます。バイナリに含まれるセクションの概要や、そのサイズおよびアドレスを把握するには、SystemV 形式の使用が推奨されます。
• Berkeley形式 (-B または--format=berkeley) GNU sizeのデフォルト形式です。Berkeley形式では、読み取り専用データは「text 」列にカウントされ、「data 」列にはカウントされません。「dec 」列と「hex 」列は、それぞれ「text 」、「data 」、「bss 」各列の合計値を10進数および16進数で表示します。
• GNU 形式 (-G または--format=gnu) GNU 形式では、読み取り専用データのカウントはtext 列ではなくdata 列で行われ、text 、data 、およびbss 各列の合計は、total 列に一度だけ表示されます。--radix オプションを使用すると、すべての列の基数を変更できます。

readelf は、ELF形式のオブジェクトファイルに関する情報を表示するためのツールです。このツールを使用すると、セクションサイズ、プログラムヘッダー、シンボルなど、バイナリから多岐にわたる情報を収集できます。アプリケーションのフットプリントを測定するには、-S 、--section-headers 、または--sections のフラグを使用して、すべてのセクション、そのサイズ、およびその他の有用な情報を取得します。

さらに、-Wl,--print-memory-usage というコンパイラフラグを使用することもできます。これにより、リンカはリンカスクリプトで設定されたすべてのメモリ領域、その実際のサイズ、および使用サイズを、バイト単位とパーセンテージの両方で表示します。

IAR

IARツールチェーンには、ELFファイルの内容をテキスト形式で表示するためのielfdumparm が提供されています。これは、IARのインストールディレクトリ内のarm/bin にあります。バイナリに含まれるセクタやセグメントに関する情報を取得するには、ielfdumparm <input> を実行してください。

各セクションに関する情報を取得する別の方法として、リンカーで--map フラグを使用する方法があります。これにより、セクションに関する詳細情報やメモリ上の配置場所が記載されたリンカーメモリマップファイルが生成されます。

ielfdumparm の詳細や、--map リンカオプションの使用方法については、『IAR C/C++ Development Guide』を参照してください。

GHS

GHSツールチェーンには、セクションサイズを測定するためのgsize ユーティリティが含まれています。これはGHSコンパイラのインストールディレクトリ内にあります。gsize はバイナリを解析し、セクションとそのサイズを出力します。-all フラグを指定すると、サイズが0のすべてのセクションも一覧表示されます。

GHSリンカーelxr には、-map オプションが用意されており、ターゲットバイナリが生成されるのと同じ場所に、独立した<target>.map ファイルを出力します。 このファイルには、バイナリに含まれるセクションやそのサイズなど、ターゲットバイナリに関する詳細な情報が含まれています。このリンカオプションはデフォルトで有効になっていますが、-map=<filename> や-nomap を指定することで変更できます。これらのオプションを使用すると、マップファイルの出力先を変更したり、マップファイルの生成を完全に無効にしたりすることができます。

gsize の詳細や、-map リンカーオプションの使用方法については、『MULTI: Building Applications for Embedded ARM』（またはターゲットアーキテクチャに応じた同等のドキュメント）を参照してください。

フラッシュメモリの使用状況

デフォルトでは、Qt Quick Ultralite には、フラッシュメモリに配置される 3 つのリソースセクションがあります。「QulFontResourceData 」、「QulResourceData 」、および「QulModuleResourceData 」セクションは、それぞれフォントアセット、画像アセット、およびQt Quick Ultralite の内部リソースを格納するために使用されます。これらのセクションに関する詳細については、「メモリ内でのリソースの配置」および「リンカースクリプトの設定」を参照してください。

これらのセクションのサイズを確認するには、「ツール」セクションで言及されているツールを使用してください。これらのツールの出力は、size -A minimal.elf の出力と類似したものになるはずです：

section                     size         addr
.flash_config                512    805307392
.ivt                        1336    805310464
.interrupts                 1024    805314560
.text                     347552    805315584
CodeQuickAccess               56    805663136
.ARM                           8    805663192
.init_array                    8    805663200
.fini_array                    8    805663208
.data                        236   2147483648
.ncache.init                   0   2197815296
.ncache                  2097152   2197815296
.bss                       13104   2147483888
QulFontResourceData        21736    805663456
QulModuleResourceData          0   2147496992
QulResourceData                0    805685192
QulPreprocessCache        524288   2147496992
.heap                          0   2148021280
.ARM.attributes               46            0
.debug_info              5402684            0
.debug_abbrev             253660            0
.debug_loc                871154            0
.debug_aranges             12520            0
.debug_ranges             100040            0
.debug_line               908143            0
.debug_str               3705172            0
.comment                      73            0
.debug_frame               51112            0
.debug_macro              570227            0
.stab                         60            0
.stabstr                     118            0
Total                   14882029

RAM使用量の推定

Qt Quick Ultraliteアプリケーションでは、以下の目的でRAMが必要です：

• フレームバッファ
• スタック
• ヒープ
• キャッシュ（テキスト、フォントエンジン、および画像用）
• リソース
• Qul アイテムデータ

以下のセクションでは、これらの項目からメモリ使用量の情報を推定または収集する方法について説明します。

フレームバッファ

長方形の画面におけるフレームバッファのサイズは、次の式で推定できます：

Framebuffer size in bytes = width x height x bytes per pixel x number of buffers

ここで

• width は画面の幅（ピクセル単位）
• height は画面の高さ（ピクセル単位）
• bytes per pixel は、1ピクセルあたりに使用されるバイト数です。ビット深度が分かっている場合は、ビット深度を8で割ることで1ピクセルあたりのバイト数を算出できます。32bppのフレームバッファの場合、1ピクセルあたりのバイト数は32 / 8 = 4 となります。
• number of buffers は、使用されるバッファリング方式によって異なります。シングルバッファリングの場合は 1、ダブルバッファリングの場合は 2 となります。

画面に使用されるフレームバッファが長方形でない場合、このサイズの見積もりは異なる可能性があります。その場合は、前述の式におけるwidth x height を、フレームバッファの総ピクセル数に置き換えることができます。

フレームバッファとその要件に関する詳細については、「フレームバッファの要件」を参照してください。

スタックとヒープ

Qt Quick Ultralite (Platform) には、スタックおよびヒープの統計情報を出力するための 2 つの関数、Qul::Platform::printStackStats およびQul::Platform::printHeapStats が用意されています。これらの関数を使用するには、プラットフォームコード内で実装する必要があります。これらの関数の実装方法の詳細については、「メモリ統計」を参照してください。

リソースキャッシュ

一般的なQt Quick 対応の Ultralite アプリケーションでは、以下の種類のキャッシュを持つことができます：

• テキストキャッシュ
• フォントエンジンキャッシュ
• 画像キャッシュ

メモリ使用量とパフォーマンスの最適なバランスをとるためには、これらのキャッシュのサイズを調整することが重要になる場合があります。アプリケーションに適したサイズを見極めるためのガイドラインを以下に示します：

テキストキャッシュ

テキストキャッシュの場合、理想的なサイズは、画面上に表示されるテキストの量と、テキストのピクセルサイズによって異なります。 たとえば、Qt Quick のUltralite最小構成サンプルにおいて、ピクセルサイズが30の「Qt for MCUs 」というテキストは、6899バイトを消費します。Textアイテムの描画に必要なグリフの境界矩形の幅は183ピクセル、高さは37ピクセルです。

テキストの不透明度を表現するにはピクセルごとに1バイト必要であるため、そのアルファマップに必要なバイト数は次のように計算できます：

183 x 37 = 6771 bytes

さらに、各キャッシュエントリには少量のメタデータが含まれているため、最終的に必要な容量はこれよりわずかに多くなります。

理想的なパフォーマンスを得るためには、1 ページからなるアプリケーションでは、そのページ上のすべてのテキストを収容できる十分な大きさのテキストキャッシュを確保する必要があります。ページの 10% がテキストで占められ、画面解像度が 800x480 の場合、800 x 480 x 10% = 38.4 Kb のテキストキャッシュで十分です。

2ページ以上あり、その間にフェードイン・フェードアウトのトランジションアニメーションがある場合は、理想的なテキストキャッシュのサイズは、両方のページのテキストをすべて収められる大きさである必要があります。

より小さなテキストキャッシュを使用すれば、パフォーマンスを多少犠牲にする代わりにメモリ使用量を抑えることができますが、その場合、アニメーションやトランジション中は、フレームごとに一部のテキストキャッシュエントリを再生成する必要が生じる可能性があります。 Monotype Spark フォントエンジンでは、静的フォントエンジンに比べてテキストキャッシュエントリの生成コストが高くなるため、パフォーマンスの問題が発生した場合は、テキストキャッシュのサイズを十分に大きく保つことが特に重要になる可能性があります。

もう1つ注意すべき点は、テキストアイテムが破棄されて再作成された場合、そのテキストアイテムが表示されると、関連するテキストキャッシュエントリも自動的に再生成されるということです。テキストや、その外観に影響を与えるその他のプロパティを変更した場合も、テキストキャッシュエントリは無効化されます。

テキストキャッシュのサイズに関する詳細については、「テキストのレンダリングとフォント」のページを参照してください。

アプリケーションで使用されているテキストキャッシュのサイズは、Qt Quick のUltraliteパフォーマンスログを確認することで確認できます。

フォントエンジンキャッシュ

Monotype Sparkフォントエンジンは、ラスタライズされる各グリフのアルファマップ用にフォントエンジンキャッシュを使用します。キャッシュの容量が十分にある場合、グリフは描画のたびに（テキストキャッシュ内、またはテキストキャッシュが無効になっている場合はフレームバッファ上に）ラスタライズされるのではなく、1回だけラスタライズされます。

たとえば、「Qt Quick 」のUltraliteサーモスタットデモでは、800x480 の解像度で、1つの言語のすべてのアルファマップを保持するために、少なくとも50 Kbのフォントエンジンキャッシュが必要です。

テキストキャッシュが十分に大きい場合、フォントエンジンキャッシュへのアクセスは、テキスト項目が最初に表示されたとき、またはテキストが変更されるたびに発生します。ただし、アニメーションが実行されている場合は、レンダリングされる各フレームごとにテキストキャッシュにアクセスされる可能性があります。 したがって、パフォーマンスの観点からは、通常、フォントエンジンキャッシュよりもテキストキャッシュに多くのメモリを割り当てる方が望ましいです。一方、フォントエンジンキャッシュはグリフ単位でキャッシュが行われるためメモリ効率が高く、同じ文字が使用されている場合、異なるテキスト項目内で同じグリフが複数回出現する可能性があります。

MCU.Config.fontVectorOutlinesDrawing が有効になっている場合、フォントエンジンキャッシュは CMAP およびアドバンスキャッシュにのみ使用され、ベクターアウトラインには使用されません。したがって、フォントエンジンキャッシュは比較的小さく抑えることができますが、ベクターアウトラインの再生成を避けるためには、テキストキャッシュを適度に大きく保つ必要があります。

フォントエンジンキャッシュのサイズに関する詳細については、「テキストのレンダリングとフォント」のページを参照してください。

アプリケーションで使用されているフォントエンジンキャッシュのサイズは、「Qt Quick 」のUltraliteパフォーマンスログを確認することで確認できます。

画像キャッシュ

画像キャッシュは、画面上に同時に表示されるすべての画像（OnDemand キャッシュポリシー適用時）を収容できる十分な大きさである必要があります。 そうしないと、大きな画像が 1 フレームごとに RAM との間で数回行き来することになり、パフォーマンスに大きな影響が出る可能性があります。これは特に、ImageFiles.MCU.resourceCompression が有効になっている場合に当てはまります。この設定では、画像を画像キャッシュに読み込む前に解凍するという追加のオーバーヘッドが発生します。

例えば、2つのページ間で遷移を行うアプリケーションを想定します。一方のページには200x200の画像が2つ、もう一方のページには320x200の画像が1つ含まれています。画像の色深度が1ピクセルあたり32ビット（4バイト）の場合、画像キャッシュの理想的なサイズは次のように計算できます：

キャッシュサイズ（遷移あり） =2 x 200 x 200 x 4 + 320 x 200 x 4 = 576000 バイト

これにより、2つのページ間の遷移アニメーションがスムーズになります。遷移アニメーションがない場合は、サイズ要件が最も大きいページを基準に計算できます：

キャッシュサイズ（トランジションなし） =2 x 200 x 200 x 4 = 320000 バイト

画像キャッシュサイズに関する詳細については、「画像キャッシュ」のページを参照してください。

アプリケーションで使用されている画像キャッシュのサイズは、Qt Quick Ultraliteのパフォーマンスログを確認することで確認できます。

プリロードされたリソースによる RAM 使用量

プリロードされたリソースが消費するRAMの量は、プロジェクトにおけるリソースのプリロード設定によって異なります。デフォルトでは、すべての画像、フォント、およびQt Quick Ultraliteのアイテムデータリソースが、アプリケーションの起動時にRAMにプリロードされます。 このオプションでは、Qt Quick Ultraliteのリソースセクションすべてを合計した際（ImageFiles.MCU.resourceCompressionを使用しない場合）、プリロードされたリソースによるRAM使用量が大きくなる可能性があります。Qt Quick Ultraliteのリソースセクションのサイズを確認する方法については、「フラッシュメモリの使用量」を参照してください。

この動作は、QmlProjectプロパティImageFiles.MCU.resourceCachePolicyを設定することで制御できます。また、ImageFiles で定義されている場合は個々のリソースごとに、MCU.Config で定義されている場合はすべてのリソースのプリロード時に設定することも可能です。 ImageFiles.MCU.resourceCachePolicyImageFiles.MCU.resourceCachePolicy を参照してください。