Top　　上へ　　目次



Ver.18系の話

　近年はChatGPTによる生成AIを利用していますが、今回は特に活躍しております。
　アイデア出すと、色々な意見を付けてくれたり、要約してくれるので、仕事はかどりますね。

　今回は操作に対する「反応/反映」に関連する性能向上がメインです。
　Ver.17のリリース前後にWindows 11のエクスプローラーの性能が大幅に上がったこともあり、性能向上の優先度が上がっていました。
　まぁ、途中で黙って処理を諦めたり、動きが変わったり、情報を破棄するのは、ものすごくバグくさくて、個人的にはいかがなものかと思いますが、気にするといった発言を見たことがありませんので、私の方の感性がずれているのかもしれません。
　（「現在のWindowsでは仕様です」は見かけてます）

　おそらく「今まで遅いと感じてなかった」と言われると思ってます。
　改修内容の概要として、ベンチマークスコアよりも、今までは遅延処理や分散処理で可能な限り隠ぺいされている部分の性能向上なので、ユーザーさんには極めて分かりにくいものとなっています。
　むしろチューニングしても性能が上がらない部分だからこそ、遅延処理や分散処理でごまかしていた・・・というのが真相であり、今までの業とかカルマというものです。
　すげぇ地味です。地味オブ地味です。

　とはいえ目立たなくても、実際CPU時間やらブロック時間で消費しているのは間違いないので、チリツモ効果で省電力化や作業時間の短縮につながると良いな・・・というのが今回のキモです。
　例えば、今まで8時間かけて作業していた業務が、15分早く終了できるようになった！俺、成長したな！という勘違いをさせられれば大成功だと思ってます。


　さて、今回の改修はVer.1.0以前から判明していたコンポーネントの欠陥に関する話でして、ネタとしてはかれこれ25年くらい温めており、ようやく解決方法が見出されたという、個人的には歴史的な快挙と言って良い「変化」になります。
　話のきっかけが、ごく最近更新されたMicrosoft社の情報公開によって・・・というオチが付くあたり、おそらくエクスプローラー側の性能向上とも話がつながっているのであろうと推測していますが、なんで今頃こんな情報が出てきたのやらです。
　またコンポーネントのバグだろ？と思われるような「急激な性能劣化が発生しなくなる」という言い方もできると思います。
　例えば、あまりにも性能が悪くて封印されていた「アイコン（旧）」の表示モードなんて、１万ファイルのうち9,999個を選択するというアクションが30分くらいかかるといった冗談のようなクソ性能でしたが、これが数ミリ秒に改善してます。

　具体的に実施した内容は、フォーカス・選択・ドロップハイライトを概ね自前で制御するようにし、リストのコンポーネント間通信で動作していた仕組みを大幅に減らした、というものです。
　これにより、多くの動作がコンポーネント間通信ではなく、単純な配列参照で情報のやり取りで行えるようになっています。
　そもそもコンポーネント間通信は、マルチコアなんて一般的ではない時代に設計されたものですし、遅いとはいえ単位は数マイクロ秒の世界です。
　これが、ナノ秒の世界に突入し、さらに並列処理が可能になった・・・というのが、今回のキモと言えるでしょう。

　特に顕著なシナリオをあげると、サブディレクトリ込みで100万アイテムあるフォルダーから、上位階層の100万アイテムあるフォルダーへ遷移する、といったシナリオの場合の時間が大幅に短縮されております。
　さすがにこれくらいの規模の鬼畜な環境では、負荷の分散や遅延処理で隠しきれないため、従来比の体感速度で4〜8倍の性能向上となります。
　この辺りの詳細を、少し紹介しておきます。


詳しい話

　As/Rの一覧を生成するロジックは、ざっくりと5段階に分かれています。
  1. 走査開始
    他スレッドの停止、前回の走査のリセット、走査スレッド生成など
  2. 走査スレッド本体
  3. 走査の後処理と受信した情報を画面に反映
    表示モード切替、フォルダ設定反映、アイコンや詳細情報の取得スレッドの生成
  4. 詳細情報/アイコン/サムネイル画像の読み込み
  5. 詳細情報/アイコン/サムネイル画像の反映
　今回「4」「5」はほとんど変わりませんので割愛します。
　今まで、主に「2」を重点的にチューニングして性能を向上させてきました。
　というのも、「1」と「3」は「UIスレッド」に属するコンポーネント間通信が足を引っ張っており、そもそも遅いAPIをどう使うか？というチューニングをしていたというものです。
　結構、いろんな工夫をして頑張ったんですけどね・・・。


　以下、新しくログバーに出力している、ベンチマーク情報を貼っておきます。
　ソート条件は「文字コード順」で、ファイル数が999,999個、サブディレクトリ2個です。
　上記の「100万アイテムあるフォルダーから、上位階層の100万アイテムあるフォルダーへ遷移」という操作です。
　CPUは、AMD Ryzen 7 7730U with Radeon Graphicsで、エントリクラスのノートPCなのでCPUもグラフィックも決して性能は高くないです。
　数値の単位は全てミリ秒です。

●Ver.17系の初期状態
BenchMark : 走査開始:前処理: 2 / 選択保存: 7873 / 一覧削除: 814 / 後処理: 1
BenchMark : Thread:パス解析: 0 /接続: 0 / 列挙: 890 / 属性: 911 / ソート: 201 / ハッシュ: 481
BenchMark : 走査終了:前処理合計: 11 / お絵描き: 7893 / 後処理合計: 10

●Ver.18系
BenchMark : 走査開始:前処理: 3 / 選択保存: 0 / 一覧削除: 226 / 後処理: 1
BenchMark : Thread:パス解析: 0 /接続: 0 / 列挙: 897 / 属性: 841 / ソート: 84 / ハッシュ: 85
BenchMark : 走査終了:前処理合計: 0 / お絵描き: 11 / 後処理合計: 0

・・・見にくいので、表にしてみました。
処理処理17系18系備考
走査開始
(UIスレッド)		 前処理23走査初期化の前処理、他のスレッドの停止など
選択保存78730フォーカス・選択の復元/セットのための状態保存
一覧削除814226現在保持している情報の破棄。並列化
後処理11スレッドパラーメータセット
走査スレッド パス解析:00アクセスしようとしているパスの解析。
存在しないものだと遅い
接続00ディスクへの接続。LAN/WAN/DVD等だと遅い
列挙:890897各種アイテムの列挙、項目数に正比例で変更なし
属性911840各種アイテムの属性の取得
並列処理のヒット率の向上と最悪ケースの発生率の減少
ほぼ限界性能なので大して伸びてない
ソート20184Ver.17.5の改修
OpenMPの廃止
ハッシュ48185Ver.17.5の改修
unorderd_mapの廃止
走査終了
(UIスレッド)		 前処理合計110描画の前処理
フォルダ設定やサムネイルキャッシュ等
改善値は定数なので伸びない
お絵描き789311走査した情報を画面に反映
後処理合計100描画処理の後処理
アイコン/詳細情報などの遅延取得スレッド生成
改善値は定数なので伸びない
　一覧の表示性能に関しては、こんなものでしょうか。
　大きく変わった部分は、赤色を塗ってみました。
　（黄色はVer.17.5あたりで実施したライブラリ変更関係の性能向上です）
　この例示は、説明のためにチョイスしただけであり、今回の性能改善のごく一部に過ぎません。

　他の例示をあげていくと、チェックボックスの動作モード「エクスプローラー風（遅い）」が、従来比20〜400倍速（桁は間違ってません）になった影響で「エクスプローラー風」に名称変更されます。
　リストのステータスエリアの「選択状態を計算する最大項目数」の初期値は10万アイテムでしたが、これ1,000万にしても平気なんで、設定が削除されています。
　ディレクトリ内検索やらインクリメンタルサーチでの項目検索、カーソル移動での選択状態の変化、上位階層へ移動する際のフォーカス位置の変更、一覧の描画そのものなど、ユーザーさんが想定しないであろうレベルまで対象まで、キビキビ感が増した・・・気がします。
　今までUIスレッドの処理が遅すぎて、処理の簡易化、遅延処理、見えないようにこっそり画面モードを切り替えるといった小細工が減り、よりシンプルな実装になったとも言えます。

　ぶっちゃけ、今までのコツコツやってきたチューニングの前提とか基盤をひっくり返した形なので、今後チューニング可能になった仕組みが山のように再出現したとも言えます。（遠い目）
　伸びしろがずいぶん増えたので、気長にチューニングをしていきたいと思います。


　あと少し、更新履歴からも紹介しておきますが、色々と頭のおかしい数字が並んでます。
　もうね「これまでクソ性能で、すまんかった」と土下座したくなるくらい、本当にえげつない性能向上率です。

　繰り返しになりますが、遅延処理や並列処理に隠れて、体感速度はこんなショッキングな数字の差を感じないはずです。
　内部情報の更新や処理がいくら速くなっても、ディスクI/O、画面への描画、人間の処理能力や認識力の限界で頭打ちになるためです。
　まぁCPUやメモリに対する負荷が減って困る人はいないはず・・・省エネにも、省力にも、待ち時間の削減にもなりますしね。

・内部データの破棄時に1,000件以上あるなら並列で破棄するように変更し、約0〜400%の性能向上
（表の赤の上から２番目）
・画面分割で左右比較で、検出解除を明示的に行い同期性を高め、約800〜1,200%の性能向上
・現在の選択状態の取得方法の抜本見直しと、情報管理の仕組みの再構築で約1,000〜2,000,000%の向上
（表の赤の上から１番目）
・情報の衝突率が最悪のケースの場合、選択状態の復元速度が約2,000〜500,000%の向上
（表の赤の上から３番目）
・アイコン（旧）/アイコンのみ（旧）のドラッグスクロールや大量選択の性能劣化がなくなった（性能向上倍率がintの桁数を超えたので計測不能）
・選択状態を保持したまま更新の処理速度が10〜500%の性能向上に伴い、中で「選択状態を保持したまま更新」を呼び出す機能全てが高速化
・各種選択系のコマンドの速度は全体的に約10〜3,000%向上


　「アイコン（旧）」の表示モードが封印されたのは、Microsoft社から公式に性能欠陥を認めた上で「仕様であるため今後の改善は行わない」とされていたからなのですが、今の速度が出るなら封印されることも無かったと思います。
　ドラッグ選択とか、「アイコン（旧）」がやっぱり楽なんですよね。
　何か上手い見せ方のアイデアが浮かべば、新しい表示モードとして大々的に復活させても良いかもしれません。
　この性能劣化のコンポーネントバグ・・・ほんとに苦しめられたなぁ・・・切ない記憶です。

デメリット

　さて、性能向上の代償です。
　従来より問題のあると認識されていた設定項目はこの機に削減してはいますが、大きな変更はないつもりです。
　とはいえ、選択状態とか、フォーカスとか、選択、ドロップハイライトに絡んで、カーソル移動やマウス操作の広範囲に影響しますし、この辺りの挙動が絡む機能全てというのは、とんでもなく広い範囲に改修範囲になっています。
　また、画面への再描画処理がポンコツだと、逆に体感速度が劣化する可能性もあり得ますし、操作してるのに画面に反映されないというバグが発生するかもしれません。(かなりの数を潰し済み)

　そのため、予期せぬバグが潜む可能性は捨てきれません。
　私自身も結構時間をかけてテストしましたが、設定の組み合わせなどで漏れがあるやもしれません。
　そのためβ版リリースを行い、テストの協力を仰ぎたい・・・というものになります。

　というわけで来週くらいから、ぼちぼちβ版をリリースしていきますので、ご協力のほど、よろしくお願いいたします。
　あ、例によってコンパイラ更新対策で全ビルドかけてるので、ウィルススキャンソフトの誤判定に耐性のある方のみでお願いします。




　デメリットというかは微妙ですけど、あまりにも長年の課題が解決した達成感がすごくて、やり切った感がスゴイんですよね。
　結構、燃え尽き感が強いです。