2

WinRT は複数の実装 (Win32 など) の上にある API ですが、COM と新しい ECMA 335/CLI メタデータのおかげで「指向オブジェクト」の方法で提供されていることがわかりました。(「Windows 8 ランタイム (WinRT / Windows ストア アプリ / Windows 10 ユニバーサル アプリ) と Silverlight および WPF の比較」を参照してください。 )

.Net 開発者として、パフォーマンスが悪いため、P/Invoke、COM、またはすべての「外部/相互運用」呼び出しを可能な限り回避することを常に学びました。(ネイティブ ライブラリの呼び出しに C++/CLI ラッパーを使用できる場合は、その方が常に優れています)

  • COM WinRT API のパフォーマンスは、従来の COM より優れていますか?
  • もしそうなら、それは ECMA 335 メタデータまたは新しい実装のおかげですか?
  • 「ボンネットの頭」には何がありますか？
4

2 に答える 2

3

COM（または基本的にCOMであるWinRT）のパフォーマンスに関する問題は、非常に「おしゃべり」（つまり、非常に短時間で多くの呼び出しを行う）またはデータマーシャリングに帰着します。

少し時間がかかるメソッド呼び出しは、常に呼び出すとパフォーマンスが低下します。したがって、WinRT呼び出しは、同じ.NETアセンブリ内のあるメソッドから別のメソッドへの呼び出しほど高速ではないと思います（JITがそれを最適化するか、重要でないように最適化すると思います）。同じレベルの最適化を行うことができない場合は、メソッド呼び出しに気付くでしょう-それをやりすぎると。たとえば、C ++での仮想メソッド呼び出しは、通常の関数呼び出しのように最適化できないvtable間接参照が必要だったという理由だけで、パフォーマンスを低下させると言われていました。

ただし、最大のパフォーマンスヒットはデータです。外部システムを呼び出すには、通常、データを他のシステムが理解できる形式に変換する必要があります。これは、実際よりも大きなパフォーマンスヒットです。データをマーシャリングする必要がない場合でも、データをコピーする必要があることがよくあります。そのため、4バイトの参照ポインターを渡す代わりに、データ全体をコピーするか、他のシステムからアクセスできるように固定する必要があります。通話環境の外。これはパフォーマンスに小さな影響を与える可能性がありますが、それでも直接呼び出しほど速くはありません。

どちらの場合も、WinRTメソッドを呼び出してもそれほど害はありません。.NETとWinRTの間にレイヤーがあります（古い自動生成されたCOMラッパーと同様）が、明らかにはるかに軽量です。

于 2012-08-21T21:16:34.830 に答える
1
  • COM WinRT APIのパフォーマンスは従来のCOMよりも優れていますか？

WinRTオブジェクトには、同等の従来のCOMオブジェクトよりも高速に実行できる魔法はありません。どちらもCOMです。ただし、より速くなるのは、市場投入までの時間です。WinRTは、開発者としての扱いがはるかに簡単です。

  • 「ボンネットの下」には何がありますか？

あなたはすでに自分でそれに答えました。

于 2012-08-21T21:04:56.723 に答える