HOME  >  スポンサー広告 >  プログラミング >  64bit で使用する Windows Automation API のパフォーマンス

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
--/--/-- | カテゴリ:スポンサー広告 | トラックバック(-) | コメント(-)

64bit で使用する Windows Automation API のパフォーマンス

Hit a Hint for Windows の処理速度改善を色々やっていて気になったところをメモ。

64bit Windows 上 での Windows Automation API のパフォーマンスについて

64bit プロセス上で Windows Automation API を使用した場合
32bit で動作しているソフトウェアに対してのレスポンスが悪い。

32bit プロセス上 (WOW64上) で Windows Automation API を使用した場合
64bit で動作しているソフトウェアに対してのレスポンスが悪い。

ソフトウェアによっては 100ms で終わっていた処理が 400ms かかる。
WOW64 のオーバーヘッドなのかなと思ったけどそれだけじゃなさそうで、
API 内部で Exception が投げられまくるときがあるのも原因だと思われる。
「クラスが登録されていません。」という Exception を投げられるときがあって、
この場合、レスポンスが悪くなるのは納得できるが、
処理上必要な情報は取得できているので Exception を投げている意味がわからない。
64bit プロセス上では 32bit の COM オブジェクトが見えないから
Exception 投げるのはまだ納得できるのだけど。。。
COM オブジェクトとれなかったら別の方法で情報取得するように API 内部で処理してるとか??
実際、 API 外部ではその Exception を catch できないし。

Exception 対策に 32bit の COM オブジェクトを 64bit 環境で使えるようにする方法もみつけたけれど、
これはレジストリを操作しなきゃならないので今回の場合は微妙。
一応リンクを。
Using a 32bit COM object in a 64bit environment

考えるのも調べるのも面倒になってきた。
何も考えずに解決するには 64bit 上のプロセスに対しては 64bit 上で、
WOW64 上のプロセスに対しては WOW64 上で Windows Automation API 動かすとかすればいいのかな。
単純に 64bit プロセスと 32bit プロセス両方立ち上げてそれぞれの環境内で処理すればいいのか。
わかりやすいし、割と自然なやり方のような気がしてきた。
この方向で改善してみようかな。
2013/11/10 | カテゴリ:プログラミング | トラックバック(0) | コメント(0)
コメントの投稿












管理者にだけ表示を許可する
トラックバック
この記事のトラックバックURL
http://uisteven.blog.fc2.com/tb.php/22-ecf8775a

外部リンク

カンパのお願い
公開しているソフトウェアはフリーウェアなので無料でご利用いただけます。 気に入ってくださった方は、Amazon でお買い物をする際に下記のリンクを経由して頂ければ励みになります。

検索BOX・タグ一覧
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。