Fork: 0
hasegawa / TIASShot
Transfer to URL with SHA Find file
Newer
Older
TIASShot / docs / 06_TEST / TEST_02_性能評価計測結果.md
Rinto Hasegawa rintoHasegawa (Rinto Hasegawa) 2 days ago 8 KB [add] v1.6 の性能評価計測結果を TEST_02 に追記
Raw Blame History

性能評価計測結果 (Performance Evaluation Results)

3 バージョン（v1.6 / v1.7 / 現行）の実機 MEMMONITOR 計測結果をまとめる．計測の目的・手段・移植方針・指標定義は PLAN_04_性能評価計測計画 を参照する．

計測条件 (Conditions)

  • 計測手段: 実機 MEMMONITOR（メモリ観測ウィンドウ＋プレビュー計測）．
  • カメラ: IScam（ImagingSource DFK 23UX249）．
  • ビルド: Debug|x64，MEMMONITOR 有効・WHITEBOARD 無効．
  • 副モニタ（セカンダリディスプレイ）: ON（F9 トグルは使わず ON のまま）．
  • サンプリング: 500ms 間隔．メモリ主指標は private_MB（Process.PrivateMemorySize64）．
  • 観測窓の実行スレッド: 旧版（bench/*）はプレビューが毎フレーム Invalidate() で本体 UI スレッドを埋めるため，観測窓を専用 UI スレッドで開く（本体・プレビューの挙動は不変の観測側の措置．同一スレッドだとグラフ描画とサンプリングが WM_PAINT 洪水に飢餓し，サンプル間隔が乱れるため）．現行はタイマー駆動で飢餓しないため同一スレッドのまま計測した．

基準プロトコル (Reference Protocol)

現行で実測した 1 本の記録を基準とし，撮影・校正の秒数を全版で揃える．撮影は単発撮影（1 枚撮影）の繰り返し．

時刻動作
0〜32 秒プレビュー放置（副モニタ ON）
32.5〜36.1 秒校正 1 回（処理時間 約 3.5 秒．アプリ側処理で固定）
62 / 92 / 123 秒単発撮影（約 30 秒間隔で 3 回）
123〜303 秒プレビュー放置（約 180 秒．プレビュー経路リークの観測区間）
303 秒単発撮影 1 回
約 348 秒停止・CSV 保存

旧版（v1.6 / v1.7）もこの秒数・順序・撮影間隔に合わせて再現し，同じ時間軸で 3 版を重ねて比較する．

現行バージョンの結果 (Current Version)

データ: data/perf_current.csv（689 サンプル・約 348 秒）．

メモリ（保存経路 S1・プレビュー経路 S2）

指標値
private_MB アイドル時ベースライン約 150 MB
private_MB 校正後の定常包絡線約 180〜200 MB（約 348 秒を通じて水平）
撮影時の一時ピーク452〜509 MB（1〜2 秒で ~180 MB に完全復帰）
終端（348 秒）の private_MB約 182 MB（校正後ベースラインと同一）
gdi_objects / handle_count68〜95 / 780〜855（単調増加なし）
  • リークなし＝天井一定．撮影のたびに 452〜509 MB へ跳ねるが確定的に解放され，包絡線は水平．180 秒のプレビュー放置区間でも上昇しない（プレビュー経路リーク修正の裏付け）．
  • グラフはのこぎり波になるが，見るべきはピーク包絡線のトレンド（PLAN_04 の「結果の読み方」参照）．

プレビュー性能（S3）

指標値
main_copy_ms（FastClone コピー時間）大半 2.3〜2.8 ms（平均 約 2.6 ms．周期的に 5〜6 ms のスパイク）
callback_fps（ShowImage 実効レート）約 30（カメラレート律速）
本モニタ実描画 FPS約 19 で一定
副モニタ実描画 FPS約 19 で一定（飢餓なし）
  • FastClone により毎フレームのコピーが約 2.6 ms．
  • 校正完了後も副モニタが約 19fps を維持＝両プレビューのタイマー駆動化により副モニタ描画飢餓が起きない（旧版の校正後 ≈2fps 飢餓と対比になる想定）．

注記（誤読を避けるため）

  • 撮影サンプル行（例 61.7 秒）で callback_fps ≈2.5・FPS ≈1 に落ちるのは，撮影が UI を約 1.5 秒同期ブロックし 500ms サンプラが 1 コマ捉えたもの．1 サンプルだけの谷で即回復＝正常挙動．
  • 30〜32 秒（校正直前）の一時的な FPS 低下はチャート検出の立ち上がりによる一過性のもの．

v1.7 の結果 (v1.7)

未計測（bench/v1.7 への計測スカフォールド移植後に基準プロトコルで再現し追記する）．

v1.6 の結果 (v1.6)

データ: data/perf_v1.6.csv（436 サンプル・約 338 秒）．bench/v1.6（v1.6 タグに MEMMONITOR 計測スカフォールドを観測フックのみ移植・プレビューのロジックは不変）で基準プロトコルを再現．

v1.6 固有の計測マッピング

v1.6 は本モニタが生フレームを直接使いコピーを持たないため main_copy_ms ≈ 0．毎フレームの全画面 Bitmap コピー（new Bitmap(bmp)＝FastClone 前の実装）は副モニタ用の sub_copy_ms に現れる．FastClone 比較はこの sub_copy_ms で読む．

メモリ（保存経路・プレビュー経路）

指標値
private_MB 開始ベースライン約 200 MB
private_MB ピーク包絡線（30 秒バケットの最大）30s:276 → 60s:539 → 90s:834 MB と上昇し，以降 660〜893 MB で高止まり・大振動
private_MB トラフ（谷）約 140〜200 MB（GC＋ファイナライザによる周期的一掃）
gdi_objects / handle_count 最大122 / 889（暴走なし）
  • リークあり＝右肩上がり後に高止まり．開始 ~200 MB から 90 秒で ~834 MB まで上昇し，以降 140〜890 MB で大きく振動する（毎フレーム new Bitmap＝原因1，副モニタ取りこぼしフレームの未 Dispose＝原因2/3 が積み上がり，GC＋ファイナライザが周期的にネイティブメモリを一掃するのこぎり波）．現行の平坦な ~200 MB 天井と対照的．
  • GDI/ハンドルは暴走しておらず，原因はネイティブ画素バッファ（メモリ）であることを裏付ける（ハンドル枯渇ではない）．

プレビュー性能

指標値
sub_copy_ms（new Bitmap 全画面コピー）平均 45.7 ms（425 フレーム平均）
main_copy_ms0（v1.6 本モニタはコピーなし）
callback_fps（ShowImage 実効レート）平均 17（最小 ~2）
副モニタ実描画 FPS sub_paint_fps平均 2.9（436 中 75 行が 0）＝描画飢餓
  • 全画面コピーが ~46 ms と重く，コールバックスレッドを律速して callback_fps を ~17 に抑える．
  • 副モニタは sub_paint_fps ≈3（しばしば 0）でほとんど描画されない＝PLAN_03 の副モニタ描画飢餓が旧版で実証された．

3 版比較 (Comparison)

現行と v1.6 を同一基準プロトコル（副モニタ ON）で比較した結果．v1.7 は移植後に追記する．

指標v1.6（旧版）現行効果
メモリ private_MB 包絡線約 200→834 MB へ上昇，140〜890 MB で振動~180〜200 MB で水平（撮影時のみ一時 ~450→即復帰）リーク解消
毎フレーム全画面コピーsub_copy_ms ≈46 ms（new Bitmap）≈2.6 ms（FastClone）約 18 倍高速化
callback_fps≈17（コピー律速）≈30コールバック律速の解消
副モニタ FPS sub_paint_fps≈3（しばしば 0）＝飢餓≈19 で一定描画飢餓の解消
GDI / handle 最大122 / 889同程度両版ともハンドル枯渇でないことを確認

→ 保存経路のメモリと合わせ，プレビュー経路のリーク・コピー律速・副モニタ飢餓が現行で解消していることが定量的に確認できた（v1.7 を加えると「保存経路は v1.6→v1.7，プレビュー経路は v1.7→現行」の切り分けが完成する）．