【要約】二十年、同じ番号を探していた ── コメント欄で教わって、その日のうちに実証した話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
筆者がExcel VBAでUI Automationの自動化を試みた際、技術的制約により効率的な実装が困難になった。従来の構成では、VBAから直接オブジェクトを生成できず、外部プロセスを介する必要があった。
- ・PowerShellを介在させることによる実行時間の増大（1.4秒）。
- ・PowerShellの実行が制限された環境での動作不能。
- ・メモリ転記処理におけるAPI呼び出しのオーバーヘッド。
// Approach
筆者は、COMの仕様に基づき、名前ではなく識別番号を用いてメソッドを直接呼び出す手法を採用した。名前による索引がないオブジェクトに対し、番号で直接アクセスすることで中間プロセスの排除を図った。
- ・CoCreateInstanceにCLSIDを直接渡し、UI Automationの本体を取得する。
- ・DispCallFuncを用い、メソッドの並び順（番号）に基づいて直接呼び出す。
- ・Windows開発キットのヘッダファイルから、正確なメソッド番号を特定する。
- ・配列の内部構造を操作する部品を用い、メモリ転記のコストを最小化する。
// Result
この手法の導入により、実行速度の向上と環境制約の解消という二つの大きな成果を得た。中間プロセスを排除したことで、自動化のパフォーマンスが劇的に改善した。
- ・電卓操作の時間が1.4秒から0.35秒へ短縮（約4倍の高速化）。
- ・PowerShell不要により、実行環境の制約を突破。
- ・メモリ転記の1回あたりの処理が0.68μsから0.03μsへ改善。
- ・UI Automationの読み取りコストに対し、転記コストを大幅に低減。
Senior Engineer Insight
> 低レイテンシを追求する姿勢は極めて実践的だ。PowerShellという抽象化を捨て、COMの低レイヤーな仕様に踏み込んでいる。これにより速度とポータビリティを両立した。ただし、ヘッダファイルによる番号管理は、OS更新時の破壊的変更リスクを伴う。本手法は、汎用的な開発ではなく、極限の性能が求められる特定の自動化エンジン等の実装に限定して適用すべきだ。