Quante sono troppe chiamate di funzione nidificate?

Citato da MSDN su StackOverflowException :

Eccezione generata quando lo stack di esecuzione trabocca perché contiene troppe chiamate di metodo nidificate.

Too manyè piuttosto vago qui. Come faccio a sapere se troppi sono davvero troppi? Migliaia di chiamate di funzione? Milioni? Presumo che debba essere in qualche modo correlato alla quantità di memoria nel computer, ma è possibile elaborare un ordine di grandezza approssimativamente accurato?

Sono preoccupato per questo perché sto sviluppando un progetto che prevede un uso intenso di strutture ricorsive e chiamate di funzioni ricorsive. Non voglio che l'applicazione non vada a buon fine quando inizio a usarla solo per piccoli test.

Sono preoccupato per questo perché sto sviluppando un progetto che prevede un uso intenso di strutture ricorsive e chiamate di funzioni ricorsive. Non voglio che l'applicazione non vada a buon fine quando inizio a usarla solo per piccoli test.

A meno che il tuo ambiente linguistico non supporti l' ottimizzazione delle chiamate di coda (e la tua ricorsione è una chiamata di coda), una regola empirica di base è: la profondità di ricorsione dovrebbe essere garantita come O (log n), cioè usando algoritmi o strutture di dati basati su divide-and- Conquer (come gli alberi, la maggior parte alogorithms smistamento, ecc) è OK, ma niente di lineare (come implementazioni ricorsive di movimentazione lista collegata) non lo è.

Per impostazione predefinita, il CLR alloca 1 MB allo stack per ogni thread (vedere questo articolo ). Quindi, sono comunque molte le chiamate necessarie per superare questo importo. Ciò varierà a seconda di quanto spazio nello stack viene utilizzato da ogni chiamata per cose come parametri e variabili locali.

Puoi anche farlo lanciare a StackOverflowExceptioncon una sola chiamata se sei disposto a essere un po 'poco ortodosso:

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

Dato che Cole Campbell ha notato le dimensioni della memoria e Michael Borgwardt ha notato l' ottimizzazione delle chiamate in coda , non le coprirò.

Un'altra cosa da tenere presente è il CPS che può essere utilizzato per ottimizzare diverse funzioni intrecciate in cui l'ottimizzazione delle chiamate di coda è per singole funzioni.

Puoi aumentare le dimensioni dello stack come abbiamo fatto qui ed essere consapevoli del fatto che il codice a 64 bit mangia lo stack più velocemente del codice a 32 bit.

Da notare che abbiamo eseguito uno degli esempi in F # interattivo per più di 40 ore senza far saltare lo stack. Sì, è stata una chiamata di funzione che è stata eseguita da sola ininterrottamente per il completamento con esito positivo.

Inoltre, se è necessario eseguire la copertura del codice per capire dove si verificano i problemi e non avere una copertura del codice con VS, è possibile utilizzare TestDriven.NET