Combien sont trop d'appels de fonction imbriqués?

Cité sur MSDN à propos de StackOverflowException :

Exception levée lorsque la pile d'exécution déborde car elle contient trop d'appels de méthode imbriqués.

Too manyest assez vague ici. Comment savoir quand trop est vraiment trop? Des milliers d'appels de fonction? Des millions? Je suppose que cela doit être lié en quelque sorte à la quantité de mémoire dans l'ordinateur, mais est-il possible de trouver un ordre de grandeur à peu près précis?

Cela m'inquiète car je développe un projet qui implique une utilisation intensive des structures récursives et des appels de fonctions récursives. Je ne veux pas que l'application échoue lorsque je commence à l'utiliser pour plus que de petits tests.

Cela m'inquiète car je développe un projet qui implique une utilisation intensive des structures récursives et des appels de fonctions récursives. Je ne veux pas que l'application échoue lorsque je commence à l'utiliser pour plus que de petits tests.

Sauf si votre environnement linguistique prend en charge l' optimisation des appels de queue (et que votre récursion est un appel de queue), une règle de base est la suivante: la profondeur de récursivité doit être garantie comme étant O (log n), c'est-à-dire en utilisant des algorithmes ou des structures de données basés sur la division et conquérir (comme les arbres, la plupart des alogorithmes de tri, etc.) est OK, mais rien de linéaire (comme les implémentations récursives de la gestion des listes liées) ne l'est pas.

Par défaut, le CLR alloue 1 Mo à la pile pour chaque thread (voir cet article ). Donc, c'est cependant de nombreux appels qu'il faut pour dépasser ce montant. Cela variera en fonction de l'espace sur la pile que chaque appel utilise pour des choses comme les paramètres et les variables locales.

Vous pouvez même lui faire lancer un StackOverflowExceptionavec un seul appel si vous êtes prêt à être un peu peu orthodoxe:

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

Puisque Cole Campbell a noté la taille de la mémoire et Michael Borgwardt a noté l' optimisation des appels de queue, je ne les couvrirai pas.

Une autre chose à savoir est CPS qui peut être utilisé pour optimiser plusieurs fonctions entrelacées où l'optimisation des appels de queue est pour des fonctions uniques.

Vous pouvez augmenter la taille de la pile comme nous l'avons fait ici , et sachez que le code 64 bits mange la pile plus rapidement que le code 32 bits.

Il convient de noter que nous avons exécuté l'un des exemples sous F # interactif pendant plus de 40 heures sans faire exploser la pile. Oui, c'était un appel de fonction qui s'est déroulé de lui-même en continu jusqu'à la fin.

En outre, si vous devez effectuer une couverture de code pour déterminer où les problèmes se produisent et que vous ne pouvez pas utiliser la couverture de code avec VS, TestDriven.NET