私の意見では、UWP / WinRTアプリケーションの開発において異常な状況が発生しています。同社は管理環境からネイティブSDKの使用を促進しています。 このアプローチがどれほど効果的かと思いまして。 そして答えとして、私はUWP / WinRT APIが提供するツールに依存して、同じ問題を解決するいくつかのアプリケーションを作成することにしました。
私の小さなテストの結果については、猫へようこそ。
問題の声明
各アプリケーションの操作アルゴリズムには、次の手順が含まれていました。
- 実行可能環境はMain（）関数を呼び出します（この関数は常にWinRT / UWPアプリケーションに存在することに驚かないでください）
- CoreApplication.Run（...）メソッドには、CreateView（）メソッドでIFrameworkViewインターフェイスを返すIFrameworkViewSource実装が渡されます。
- いくつかの初期化手順の後、IFrameworkView.Run（）メソッドが呼び出されます。これにより、メインアプリケーションウィンドウがアクティブになり、イベントのディスパッチャー処理が開始され、計算を実行するスレッド/タスクが作成されます。
計算の実行に必要な時間をより正確に測定するために、デバッガーなしでアプリケーションが起動されました。 結果と経過時間の値は、それぞれ「結果」アプリケーションと「時間」アプリケーションのローカル設定のフィールドに入力されました。
すべての計算を実行するのに必要な時間を測定するシーケンスは次のとおりです。
- 変数の初期化
- 開始タイマー/開始時間変数の初期化
- 複数の変換：入力-> SHA256ハッシュ-> Base64文字列->入力
- タイマーの停止/経過時間の計算
- ローカル設定への値の書き込み
格納された値を読み取るために、アプリケーションがデバッグモードで起動され、データがコンソールに表示されました。
合計で5つのテストアプリケーションプロジェクトが作成され、そのうち3つは作業でUWP / WinRT APIを使用し、2つは独自のSHA256およびBase64の実装に依存していました。
アプリケーションの一般的なリスト：
C＃で記述されたプロジェクトは、通常の実行に加えて、.NET Nativeを使用したコンパイルモードでもテストされました。
試験結果
テストは、ARMとx86の2つのコンパイルおよび実行モードで実行されました。
以下はランタイムチャートです（値はミリ秒単位です）。
このような大きな違いは私を少し驚かせました。 理解するために、UWP / WinRT APIを使用してアプリケーションのプロファイルを作成することにしました。
すべてのスクリーンショットをテーブルに縮小すると、次のものを取得できます。
このような大きな違いの理由に気付くのは簡単です：WRLを使用して純粋なC ++で記述されたプロジェクトでは、CryptoWinRT.dllライブラリからのコードランタイムは90％に達し、.NET Nativeを使用してコンパイルされたC＃プロジェクトでは、この値はわずか15％ 。 そのため、ほとんどの場合、C＃で作成されたプロジェクトはアイドル状態で動作します。
おわりに
もちろん、現実から離れた場所でUWP / WinRT APIを使用する方法が選択されていることは明らかです。 ほとんどの場合、このようなコードはまったく発生しません。 ただし、状況によっては、言語プロジェクションを使用した結果として発生するオーバーヘッドのために、コードの動作が非常に遅くなることがあります。 この場合の最善の解決策は、システムAPIを使用せずに、同様のタスクを実行する代替実装でしょう。
すべてのプロジェクトのソースコードは、
https：//github.com/altk/sha256comparisonで入手できます
。