ネストされた関数呼び出しが多すぎますか？

StackOverflowExceptionについてMSDNから引用：

ネストされたメソッド呼び出しが多すぎるために実行スタックがオーバーフローしたときにスローされる例外。

Too manyここはかなりあいまいです。多すぎると本当に多すぎることをどのようにして知ることができますか？何千もの関数呼び出し？何百万人？私はそれが何らかの形でコンピュータのメモリの量に関係しているに違いないと思いますが、大体正確な大きさのオーダーを考え出すことは可能ですか？

再帰構造と再帰関数呼び出しを多用するプロジェクトを開発しているので、これが心配です。ほんの小さなテスト以上に使用し始めたときに、アプリケーションが失敗するのは望ましくありません。

再帰構造と再帰関数呼び出しを多用するプロジェクトを開発しているので、これが心配です。ほんの小さなテスト以上に使用し始めたときに、アプリケーションが失敗するのは望ましくありません。

お使いの言語環境サポートのない限り、末尾呼び出しの最適化（とあなたの再帰がある末尾呼び出し）、親指の基本的なルールは次のとおりです。再帰の深さはに基づくアルゴリズムやデータ構造を使用してO（Nログ）、すなわちであることが保証されなければならないディバイド・アンド・征服（ツリー、ほとんどのソートアルゴリズムなど）は問題ありませんが、線形（リンクリスト処理の再帰的実装など）は問題です。

デフォルトでは、CLRは各スレッドのスタックに1 MBを割り当てます（この記事を参照）。したがって、この量を超えるには多くの呼び出しが必要です。これは、各呼び出しがパラメーターやローカル変数などに使用しているスタック上のスペースによって異なります。

StackOverflowException少し正統派ではない場合は、1回の呼び出しでスローすることもできます。

private static unsafe void BlowUpTheStack()
{
    var x = stackalloc byte[1000000000];
    Console.WriteLine("Oh no, I've blown up the stack!");
}

コールキャンベルが指摘したのでメモリサイズをとマイケルBorgwardtは指摘テール呼び出しの最適化を、私はそれらをカバーしています。

知っておくべきもう1つのことは、テールコールの最適化が単一の関数に対して行われる複数の織り交ぜられた関数を最適化するために使用できるCPSです。

ここで行ったようにスタックのサイズを増やすことができます。また、64ビットコードは32ビットコードよりも速くスタックを消費することに注意してください。

注目に値するのは、スタックを爆破せずに40時間以上F＃interactiveでサンプルの1つを実行したことです。はい、正常に完了するまで継続的に単独で実行されたのは1つの関数呼び出しでした。

また、問題が発生した場所を把握するためにコードカバレッジを行う必要があり、使用できるVSでコードカバレッジがない場合は、TestDriven.NET