WPF アプリケーションがあり、デバッグ目的の場合、コンソールにメッセージが表示されます。これは、Windows アプリケーションとして構成され、コンソールが表示されていない場合、アプリケーションのパフォーマンスに影響しますか?
4 に答える
Console.WriteLine() の本当のボトルネックは、実際にコンソールに書き込むことです。特にコンソールをスクロールする必要がある場合、これは非常に高価です。また、コンソールがない場合に出力をキャプチャし、代わりに [出力] ウィンドウに表示する Visual Studio ホスティング プロセスにもかなりのオーバーヘッドがあります。
アプリをデプロイした後は、どちらも役割を果たしません。しかし、はい、すべてのメソッド呼び出しが行われ、文字列がフォーマットされています。Windows API 関数がコンソールがないことを発見した最後の可能な瞬間にのみ、ビットバケットに分類されます。
Debug ビルドでの実行時にアプリのパフォーマンスが許容範囲内であれば、心配する必要はありません。デバッガーを使用しないリリース ビルドで優れたパフォーマンスが得られず、Console.WriteLine() が原因である可能性があると思われる場合は、ためらわずに検索して Debug.Print() に置き換えてください。
ボトルネックは、それがコード内で最も遅いポイントであることを意味します。あなたがしていることをすべて知らなければ、それを知ることはできません。
パフォーマンスへの影響はまったくありますか、はい、おそらく。何もしていないのではなく、何かをしているのです。あなたのプログラムのボトルネックになるだけで十分でしょうか。私はそれを非常に疑います。目立った影響を与えるのに十分なのか、それは可能ですが、可能性は低いです. それはすべて、プログラムが他に何を行っているか、およびコンソールにどれだけ書き込みを行っているかによって異なります (時間がかかることに気付くには、かなりの時間がかかる必要があります)。
コメントで述べたように、デバッグ時に出力を確認できるようにでDebug.WriteLine
はなく使用できConsole.WriteLine
ますが、リリース ビルドをコンパイルすると、これらのステートメントは出力されません。
独自のロギング フレームワークを構築して最適化することが最善の方法になることはめったにありません。
log4net のようなものを見たことがありますか? コンソールへのロギングなど、さまざまなアペンダーを構成できます。非同期アペンダーを構築して、ロギングのオーバーヘッドを大幅に削減することもできます。
エリック
何かをすることは、何もしないことよりも常に時間がかかります。
ヌル コンソールにテキストを書き込む行為は、パフォーマンスに大きな影響を与えるべきではありませんが、パラメーターとして渡す内容とそのボリュームは影響を受ける可能性があります。
コンソール出力の有無にかかわらず実際のパフォーマンスを測定して、使用パターンが許容範囲内にあるかどうかを自分で確認してください。
Debug.WriteLine() は、リリース用にビルドするときに自動的に除外されるため、要件によってはより適切な選択になる可能性があります。