これは非常に遅いです:
try
{
x = k / y;
}
catch (DivideByZeroException) { }
これは約 5 倍高速です。
if (y > 0) x = k / y;
理由を教えてもらえますか?
これは非常に遅いです:
try
{
x = k / y;
}
catch (DivideByZeroException) { }
これは約 5 倍高速です。
if (y > 0) x = k / y;
理由を教えてもらえますか?
わずか5倍高速?あなたは私を驚かせます。おそらく、サンプル データに多くのゼロが含まれていないことを意味します。
例外は、単純な比較よりもコストがかかります。正しく使用した場合 (つまり、例外的な状況の場合)、パフォーマンスが大幅に低下する傾向はありません。大きな影響を与えるのに十分な例外をスローしている場合、サービスが既に停止している可能性があるためです。このような非常に簡単にテストできる条件を無視しようとするために例外を使用すると、問題が発生します。
例外のコストについて注意すべき点は、デバッガーを接続せずに実行する場合よりも、デバッガーの方がはるかに多くのコストがかかることです。特に、一連のリソースをロードする必要がある最初の例外は、マイクロ/ミリ秒ではなく数秒かかる場合があります。コードをベンチマークする場合は、デバッガーで実行しないことが重要です。これは一般的に当てはまりますが、例外の場合は特にそうです。
例外はコストがかかるためです。
例外がスローされると、ランタイムは大量の情報 (スタック トレースなど) を取り出してバブルアップする必要があります。これには時間とリソースがかかりますが、値 0 のテストは比較的安価です。
詳細については、このSOの質問を参照して、例外のコストがどれほど高いかを尋ねてください。
例外はチェックよりも遅いためです。if
通常、例外には、単純なステートメントにはない多くのインフラストラクチャがあります。
この場合のように使用しないことを選択した場合でも、例外で多くの情報が配信されるため、これらは同等の操作ではありません。
例外が遅いのはなぜですか?
例外がスローされてキャッチされると、多くのことが発生するためです。詳細については、マネージ例外モデルに関する Chris Brumme の投稿と、基になる Win32 SEH モデルに関するこの投稿を参照してください。
簡単なテストが速いのはなぜですか?
2 つの整数の比較の結果に応じてジャンプする 1 つの命令を実行するだけなので、例外よりもはるかに少ない作業です。
それは、常に例外を回避しようとする必要があるということですか?
いいえ、セマンティクスに依存します。ゼロ除算が、発生することが予想されず、プログラムが合理的に処理できない真の例外ケースである場合は、例外を発生させてプログラムをクラッシュさせます。ただし、これが予期されたケースであり、合理的な方法で処理できる場合は、例外を回避するのが妥当と思われます。
この記事を見てください:
例外が非常に遅い- これが、.Net フレームワークに TryParse メソッドがある理由です。
// This is much quicker...
double result;
if (!double.TryParse("Twelve", out result))
{
result = -1;
}
return result;
// Than this...
try
{
return double.Parse("Twelve");
}
catch
{
return -1;
}
常に例外を回避するように努める必要があります (例外的な状況を除いて - ハハ...)