はConsole.WriteLineでWindowsアプリケーションのボトルネックですか？

Question

WPFアプリケーションがあり、デバッグ目的でコンソールに表示されているメッセージがあります。これは、アプリケーションがWindowsアプリケーションとして構成され、コンソールが表示されていない場合、アプリケーションのパフォーマンスに影響しますか？

Answer 1

Console.WriteLine（）の実際のボトルネックは実際にコンソールに書き込んでいます。 は本当にで、特にコンソールをスクロールする必要があるときには高価です。 Visual Studioのホスティング・プロセスには、コンソールがなく、出力ウィンドウに表示されているときに出力をキャプチャするかなりのオーバーヘッドもあります。

あなたのアプリケーションを配備した後もどちらも役割を果たしません。しかし、はい、すべてのメソッド呼び出しが行われていて、文字列がフォーマットされています。Windows api関数がコンソールがないことが判明したときには、ビットバケットにしか落ちません。

デバッグビルドで実行しているときに、アプリが許容範囲内であれば、心配する必要はありません。デバッガなしでリリースビルドに恒星のperfが表示されず、Console.WriteLine（）によって引き起こされた可能性があると思うなら、Search + Debug.Print（）に置き換えてください。

Answer 2

ボトルネックは、コード内で最も遅いことを意味します。あなたがやっていることを他に知っていなければ、それを知ることはできません。

おそらく、パフォーマンスの影響はありますか？それは何もしていない、それは何かをやっている。あなたのプログラムのボトルネックには十分であろうか、私はそれを非常に疑っています。それは目に見える影響を及ぼすことさえあれば十分ですが、それは可能ですが、ありそうもありません。それはあなたのプログラムが何をしているのか、コンソールに書き込んでいる量に依存します（それにかかる時間に気付くにはかなりの時間が必要です）。

コメントは、Console.WriteLineではなくDebug.WriteLineを使用すると、デバッグ時に出力を確認できますが、リリースビルドをコンパイルすると、それらの文は印刷されません。

Answer 3

何かをすることは何もしないよりも時間がかかります。

Nullコンソールにテキストを書き込む行為は、パフォーマンス上の大きなヒットではなく、パラメータとして渡される内容とどのような量であるべきかを示します。

コンソールの出力の有無にかかわらず実際のパフォーマンスを測定し、使用パターンが許容範囲内かどうかを自分で確認します。

Debug.WriteLine（）は、リリース用にビルドするときに自動的に除外されるため、要件に応じてより適切な選択肢になります。

Answer 4

独自のログフレームワークを構築して最適化するのは、めったに最適な方法ではありません。

あなたはlog4netのようなものを見ましたか？コンソールへのロギングなど、さまざまなアペンダーを設定できます。また、非同期アペンダーを作成して、ロギングオーバーヘッドを大幅に削減することもできます。

erick