Excel スプレッドシートを作成するために、ClosedXML ライブラリにアクセスする比較的単純なコンソール ユーティリティを作成しました。驚異的なことは何もなく、非常に高速に実行されるはずです。ただし、起動すると、進行状況を表示する前にコンソール画面に約 8 秒間表示されます。
最初は、これは ClosedXML ライブラリの初期化に時間がかかるものだと思いました。dotTrace を起動し、行ごとのパフォーマンス分析を実行したところ、いくつかの奇妙な結果が得られました。
- メインスレッド [14,352ms]
- メイン [99.29% - 14,251ms]
- 生成 [88.88% - 12,756ms]
- 合計 23.44% / 4,360 ミリ秒の 11 のリストされた呼び出し
- get_Instance [6.78% - 974ms]
- Console.ReadLine [2.75% - 394ms]
- ポリシーの解決 [0.82% - 118ms]
- 11の隠し機能 [0.01% - 1ms]
- 生成 [88.88% - 12,756ms]
- ポリシーの解決 [0.20% - 29ms]
- 0.51% / 72ms になる 7 つのリストされた呼び出し
- メイン [99.29% - 14,251ms]
- スレッド「.NET SystemEvents」[3,074ms]
- スレッドスタート [100% - 3,074ms]
- 実行 [99.6% - 3,072ms]
- ThreadStart_Context [99.93% - 3,072ms]
- 実行 [99.6% - 3,072ms]
- スレッドスタート [100% - 3,074ms]
を掘り下げるとThreadStart_Context
、次のことがわかります。
- System.Threading.ThreadHelper.ThreadStart_Context(オブジェクト) [99.93% - 3,072ms]
- Microsoft.Win32.SystemEvents.WindowThreadProc [99.90% - 3,071ms]
- Microsoft.Win32.UnsafeNativeMethods.MsgWaitForMultipleObjectsEx [87.26% - 2,682ms]
- Microsoft.Win32.SystemEvents.WindowThreadProc [99.90% - 3,071ms]
MsgWaitForMultipleObjectsEx
プロファイラーによると、API は合計 26 回呼び出されます。これは、待機ごとに約 100 ミリ秒待機していることを意味します。
このGenerate
メソッドは私が作成したもので、ClosedXML ライブラリと頻繁にやり取りします。操作の一部にはディスクへの書き込みが含まれますが、これは最後に、コンソール出力が表示された後に行われます。遅延は、作業が完了する前に発生します。
私の懸念は 2 つあります。
Generate
メイン スレッドでの呼び出しの結果に 8,396 ミリ秒の時間差があるのはなぜですか?- への呼び出しが非常に多く
MsgWaitForMultipleObjectsEx
、合計 3 秒かかるのはなぜですか? これはスレッド同期が原因である可能性があることは理解していますが、アプリケーションにはスレッドが 1 つしかありません。
更新: 2 番目のスレッドが実際にメッセージ ループを処理していることがわかったので、そこで 5 秒間費やされたのは、処理するウィンドウ メッセージがない領域だけです。ただし、その 8 秒の不一致がどこにあるのかはまだわかりません。