再利用を促進する小さなメソッドを作成するのが良い方法であることは誰もが知っていますが、これにより多くのメソッドがスタックに置かれることは避けられません。ただし、ネストされたメソッド呼び出しが多すぎてStackOverflow Exception が発生するシナリオに到達することは可能ですか?
受け入れられる解決策は、単純にスタック サイズを増やすことでしょうか?
ドキュメントには、「非常に深い再帰または無制限の再帰」中にそのような例外が発生すると記載されているため、確かに可能であると思われますか、.NET フレームワークはスタック サイズを動的に処理しますか?
私の質問は次のように要約できます。
スタックサイズを増やしてより多くのリソースを使用するために必要になるような、適切に設計されたプログラム (小さな再利用可能なメソッドの観点から) を持つことは可能ですか?
.NET スタック サイズは固定で、既定では 1 MB です。
スタックサイズを増やしてより多くのリソースを使用するために必要になるような (小さな再利用可能なメソッドに関して) よく設計されたプログラムを持つことは可能ですか?
ロジックをメソッドに分解することにはなりません。
直接的なバグではないスタック オーバーフローに遭遇する唯一の方法は、再帰を使用することです。そして、それが発生した場合 (脅威となる場合) は、スタックを増やすのではなく、コードを書き直して、別の方法でデータを格納するようにします (a などStack<T>)。
あまり。非常に簡単なテストを行ったところ、15,000 回のネストされた呼び出しの後に StackOverflowException が発生しました。
メソッドの数が非常に多いため、非再帰的に 15,000 回ネストするコードを作成する方法はありません。
明らかに、正確な数は、スタックに割り当てた多くの関数ローカル変数に依存します。しかし、その実際の数が何であれ、あなたが提案していることを実行するには十分ではありません.
マネージドの世界では、スタックはパフォーマンスに対して特別な役割を果たします。(プリミティブまたは構造体を使用して) スタックに何かを割り当てることができた場合、それをヒープに置く必要はありません。ヒープに割り当てると、平均してプログラムの速度が低下する GC 圧力が追加されます。
そのため、スタックに多くのものを割り当てることで、より高速なプログラムをイメージできました。stackallocを使用しても(C#/CLR のあまり知られていない機能です)。
これを行う有効なケースがあります。それらはまれです。「有効な用途がない」と言うだけでは、明らかに間違っています。