含まれていない場合に例外をキャッチするよりも、辞書にキーが含まれているかどうかをチェックする方が速いのはなぜですか？

コードを想像してください：

public class obj
{
    // elided
}

public static Dictionary<string, obj> dict = new Dictionary<string, obj>();

方法1

public static obj FromDict1(string name)
{
    if (dict.ContainsKey(name))
    {
        return dict[name];
    }
    return null;
}

方法2

public static obj FromDict2(string name)
{
    try
    {
        return dict[name];
    }
    catch (KeyNotFoundException)
    {
        return null;
    }
}

これらの2つの関数のパフォーマンスに違いがあるかどうか気になったのは、最初の関数は2番目の関数よりも遅い必要があるためです。一度だけですが、WOW、それは実際には反対です：

1 000 000値のループ（100 000が存在し、900 000が存在しない）：

最初の関数：306ミリ秒

2番目の関数：20483ミリ秒

何故ですか？

編集：この質問の下のコメントでわかるように、2番目の関数のパフォーマンスは、実際には存在しないキーが0の場合、最初の関数よりもわずかに優れています。ただし、存在しないキーが少なくとも1つ以上存在すると、2番目のキーのパフォーマンスは急速に低下します。

一方では、スタックをほどく必要があるため、例外をスローすることは本質的にコストがかかります。
他方、そのキーによってディクショナリ内の値にアクセスすることは、高速なO（1）操作であるため安価です。

ところで：これを行う正しい方法は使用することです TryGetValue

obj item;
if(!dict.TryGetValue(name, out item))
    return null;
return item;

これは、2回ではなく1回だけ辞書にアクセスします。キーが存在しない
場合に本当に戻りたいnull場合は、上記のコードをさらに簡略化できます。

obj item;
dict.TryGetValue(name, out item);
return item;

これは、キーが存在しない場合にTryGetValue設定itemさnullれるため機能しnameます。

辞書は、特に超高速のキー検索を行うように設計されています。それらはハッシュテーブルとして実装され、エントリが多いほど、他のメソッドと比較して高速になります。例外エンジンは、エラーを処理するための多くの機能を提供する大規模なオブジェクトのセットであるため、メソッドが設計どおりに実行できなかった場合にのみ使用することが想定されています。私はライブラリクラス全体を一度ビルドし、すべてを一度try catchブロックで囲み、600以上の例外の1つ1つに個別の行を含むデバッグ出力を確認してびっくりしました！