Je n'ai généralement aucun problème à décider si certaines données doivent être globales, statiques ou sur la pile (pas d'allocation dynamique ici, donc pas d'utilisation du tas). J'ai également lu quelques questions / réponses comme celle-ci, mais ma question est plus précise car elle implique une énorme quantité de données, énorme par rapport à la mémoire système.
Je travaille un code existant que j'essaye d'améliorer (design, problèmes possibles, performances, etc.). Ce code fonctionne sur un ancien MCU 8 bits avec seulement 4 Ko de RAM . Dans ce code, je suis confronté à l'utilisation d'un tableau de près de 1 Ko (oui, 1 Ko sur un système de RAM de 4 Ko ). Chaque octet de ce tableau est utilisé, ce n'est pas la question. Le problème est que ce tableau est un tableau statique dans le fichier où il est déclaré, donc son cycle de vie est le même que celui du programme (c'est-à-dire qu'il peut être considéré comme infini).
Cependant, après avoir lu le code, je viens de découvrir que ce tableau n'a pas besoin d'un cycle de vie infini, il est construit et traité de manière entièrement procédurale, nous devrions donc pouvoir le déclarer uniquement dans la fonction où il est utilisé, de cette façon, ce serait sur la pile, et nous économiserions donc ce 1 Ko de RAM.
Maintenant, la question: serait-ce une bonne idée? Du point de vue de la conception, s'il n'a pas besoin d'un cycle de vie infini / global, il appartient à la pile. Mais bon, c'est 1 Ko sur 4 Ko, n'y a-t-il pas d'inconvénient à allouer 25% de la RAM comme ça? (cela pourrait représenter 50% ou plus de la pile)
Quelqu'un pourrait-il partager une certaine expérience avec ce genre de situation, ou est-ce que quelqu'un pense à une raison valable de ne pas mettre ce tableau sur la pile? Je recherche des inconvénients techniques ainsi que des commentaires sur le design.
La seule chose dont je suis conscient, c'est que je dois m'assurer que j'ai réellement 1 Ko de pile libre en entrant dans cette fonction. Peut-être que c'est tout ce dont je dois m'occuper, peut-être pas.