このトピックでは、Qt Quick Ultralite アプリケーションのパフォーマンス・メトリクスとメモリ・フットプリント情報を取得する方法に焦点を当てます。

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

Qt Quick Ultralite は以下のような重要なパフォーマンスメトリックを収集できます。

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

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

• 性能メトリクスを収集するには、Qt Quick Ultralite CoreライブラリをQUL_ENABLE_PERFORMANCE_LOGGING CMakeオプションを有効にしてビルドする必要があります。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パフォーマンスログ機能を有効にするには、-DQUL_ENABLE_PERFORMANCE_LOGGING=on CMakeオプション（Qt for MCUs 2.6でデフォルトで有効になっています）を使用して、Qt Quick Ultralite Coreライブラリを再構築します。-DQUL_ENABLE_PERFORMANCE_CONSOLE_OUTPUT=on CMakeオプションと先のオプションを併用することで、シリアルコンソールを介してロギング出力を指示することができます。

パフォーマンスロギングが有効になっている場合、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で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
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 フォントエンジンキャッシュの現在の使用量と総容量がそれぞれ表示されます。

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

次は、レンダリングに1、2、または3回のリフレッシュ（vsync）間隔を要したフレーム数に関する情報です。毎秒60フレームで一貫してレンダリングするためには、すべてのフレームが1回のリフレッシュインターバル内にレンダリングを完了しなければなりません。

10 fps」行（最後の31フレーム）は、これらの統計が前の31フレーム、平均10フレーム/秒であることを意味します。

最後に、Qt Quick Ultraliteレンダリングパイプラインのさまざまな部分のタイミング統計です。avg "値は特定のフレームに費やされた平均時間を表し、"worst "値は1つのフレームに費やされた最長時間を表します。ログに表示されるさまざまなタイミング統計の概要は次のとおりです：

CPU 使用率

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

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

CPU Load: 44.47

この例は、CPU負荷が44.47 %であることを意味します。CPUは半分以上の時間、アイドル状態であった。

メモリフットプリント

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

ツール

ツールチェーン固有のツールを使用して、アプリケーション・バイナリによるメモリ消費量を調べることができます。これらのツールは異なるフラグを持ち、異なる出力を生成します。以下のサブセクションでは、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 フォーマットを使うことが推奨される。
• バークレー・フォーマット (-B または--format=berkeley) GNU サイズのデフォルト・フォーマット。バークレー・フォーマットでは、data 列ではなく、text 列の読み取り専用データをカウントする。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 toolchain は、ELF ファイルの内容をテキストで表示するielfdumparm を提供しています。これは、IAR のインストールディレクトリのarm/bin にあります。バイナリに含まれるセクタとセグメントに関する情報を得るには、ielfdumparm <input> を実行してください。

別のセクションに関する情報を得るには、リンカで--map フラグを使用します。これはリンカのメモリマップファイルを生成し、セクションとそれらがメモリ上のどこに配置され ているかについての詳細な情報を含んでいます。

ielfdumparm または--map リンカオプションの使用法についての詳細は、IAR C/C++ 開発ガイドを参照してください。

GHS

GHS ツールチェーンには、セクションサイズを測定するためのユーティリティgsize があります。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 は各ピクセルに使用されるバイト数。ビット深度がわかっていれば、ビット深度を8で割ることでピクセルあたりのバイト数を計算できます。32bppフレームバッファの場合、ピクセルあたりのバイト数は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 バイトを消費します。テ キ ス ト アイテムの描画に必要なグ リ フ の外接矩形は幅 183 ピ ク セル、 高 さ 37 ピ ク セルです。

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

183 x 37 = 6771 bytes

さらに、各キャッシュ・エントリには少量のメタデータが含まれるため、最終的な必要量は若干多くなります。

理想的なパフォーマンスを得るためには、単一ページのアプリケーションは、少なくともそのページ上のすべてのテキストを収容するのに十分な大きさのテキストキャッシュを持つべきです。ページの10％がテキストで覆われ、画面解像度が800x480の場合、800 x 480 x 10% = 38.4 Kb テキスト・キャッシュで十分です。

2つ以上のページがあり、それらの間にフェード遷移アニメーションがある場合、理想的なテキストキャッシュのサイズは、両方のページのテキストを収めることができるはずです。

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

テ キ ス ト ア イ テ ム を破棄 し て再作成す る と 、 テ キ ス ト ア イ テ ムが表示 さ れ る よ う にな っ た時点で、 関連す る テ キ ス ト キ ャ ッ シ ュ 項目 も 自動的に再生成 さ れます。テキストを変更したり、外観に影響するプロパティを変更したりすると、テキストキャッシュエントリも無効になります。

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

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

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

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

たとえば、Qt Quick Ultralite Thermostat Demoは、800x480 の解像度で、単一の言語のすべてのアルファマップを保持するために、少なくとも 50 Kb のフォントエンジンキャッシュを必要とします。

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

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

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

アプリケーションが使用するフォントエンジンキャッシュサイズは、Qt Quick Ultraliteのパフォーマンスログを見ればわかります。

画像キャッシュ

画像キャッシュは、画面に同時に表示されるすべての画像（OnDemand キャッシュポリシー付き）を収めるのに十分な大きさでなければなりません。そうでないと、大きな画像がフレームごとに何度もRAMに入ったり出たりして、パフォーマンスに大きな影響を与える可能性があります。これは特にImageFiles.MCU.resourceCompressionが有効になっている場合に当てはまり、画像キャッシュに読み込む前に画像を解凍するオーバーヘッドが追加されます。

たとえば、200x200の画像を2枚含むページと、320x200の画像を1枚含むページの2つのページを遷移するアプリケーションがあるとします。画像の色深度が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 にプリロードされます。このオプションを使用すると、プリロードされたリソースの RAM 使用量が、（ImageFiles.MCU.resourceCompression を使用しない）すべてのQt Quick Ultralite リソースセクションの合計で高くなる可能性があります。Qt Quick Ultraliteリソースセクションのサイズを取得する方法については、フラッシュメモリ使用量を参照してください。

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