Mallocs et mémoire en gruyère

**Anonymouse** · 18/12/2008, 20h52

Bonjour,

J'ai ouï dire que l'abus de malloc transformait la mémoire en gruyère et qu'il fallait l'éviter.
Tout d'abord j'aimerai savoir si cela est vrai.

Je vous expose mon problème:
J'ai une fonction récursive qui prend un path pour paramètre et se rappelle se passant un autre path composé du path de base + d'un nom de fichier/dossier et ceci sur tout une arborescence. Pour le moment a chaque ré-appel je fais un nouveau malloc.

J'ai également une "classe" de gestion de chaine de caractères dynamique qui utilise réalloc.

Est-ce que cela vaut le coup de remplacer ma suite de malloc/free par ma chaine dynamique qui utilise realloc??

Merci d'avance de vos réponses

**matafan** · 19/12/2008, 00h06

malloc() c'est la seule façon d'allouer de la mémoire dynamiquement. Il est donc difficile de s'en passer...

Par contre si tu as un grand nombre de petites structures allouées dynamiquement, il n'est pas forcément très efficace de faire chaque allocation indépendament, car les appels à malloc() sont relativement couteux. Si c'est une zone critique au niveau des perf, il vaut mieux se débrouiller pour faire les allocations par gros blocs. Mais bon c'est de l'optimisation, tant que tu n'en a pas besoin c'est pas la peine de passer du temps là dessus.

**souviron34** · 19/12/2008, 11h19

Envoyé par Anonymouse

Est-ce que cela vaut le coup de remplacer ma suite de malloc/free par ma chaine dynamique qui utilise realloc??

En général c'est le contraire : un realloc d'une certaine taille génère des trous, beaucoup plus difficilement remplissables que des petits allocs/free...

Si donc on veut maintenir une taille raisonnable (et relativement correcte) de la mémoire, il est préférentiel d'utiliser effectivement des listes chaînées où chaque élément est alloué/libéré séparément, que des tableaux réalloués...

J'avais fait un schéma il y a un certain temps, faudrait que je fouille. Mais c'est assez facile à comprendre dès qu'on le fait...

**Anonymouse** · 20/12/2008, 08h35

Envoyé par souviron34

En général c'est le contraire : un realloc d'une certaine taille génère des trous, beaucoup plus difficilement remplissables que des petits allocs/free...

Si donc on veut maintenir une taille raisonnable (et relativement correcte) de la mémoire, il est préférentiel d'utiliser effectivement des listes chaînées où chaque élément est alloué/libéré séparément, que des tableaux réalloués...

J'avais fait un schéma il y a un certain temps, faudrait que je fouille. Mais c'est assez facile à comprendre dès qu'on le fait...

Bonjours

Je vous remercie de vos réponses j'ai donc décidé de laisser le code tel-quel.

Merci

**souviron34** · 20/12/2008, 15h18

j'ai retrouvé le schéma et la discussion :

post 21/

et

Les pointeurs qu'est-ce ?

**Anonymouse** · 25/12/2008, 03h26

Ok je viens de lire la discussion.

Ca tombe bien j'utilise beaucoup les arbres et listes chainées

**Pierre Maurette** · 28/12/2008, 11h21

Bonjour,

Je ne réponds pas directement à la question - c'est d'ailleurs déjà fait - mais je papote par rapport à la récursivité.

Le parcours récursif d'une arborescence est un classique indépendant du langage de programmation. Souvent, ça marche très bien dans un contexte, on réutilise dans un autre contexte, et là des soucis - overflow et performance particulièrement - peuvent apparaître. Il est donc important de ne pas sous-optimiser dès le départ. Il faut également être parcimonieux avec les variables propres à chaque "instance"(*).

Ici, de dernier point ne pose pas de problème, puisque seul le retour du malloc() sera ajouté aux variables locales. En fait généralement au contexte de l'instance dans la pile.

Mais si le travail utile de la fonction est léger, la séquence [malloc(), vérification, free()] pourra devenir pénalisante. Ensuite, il faut voir que quand le code sera par exemple à un point bas de la pile d'appel, il y aura "beaucoup", voire "très beaucoup", d'instances vivantes, et autant de blocs malloc-és - sur le tas, typiquement -, dont un seul sera actif, celui de l'instance active. La question qui se pose est de savoir si le contenu du bloc d'une instance est utile quand le code n'est plus dans l'instance.

La question à se poser avant toute autre, c'est: ai-je dans ma fonction des appels récursifs entre un ??alloc() et le free() ou realloc() correspondant ? Ou plus généralement puis-je réorganiser mon code pour obtenir cette caractéristique, quitte à ajouter un free() puis un malloc() pour "passer" un appel récursif ? Ici, pas question de performance, même si ça amène à mettre les appels à ??alloc() et free() dans une boucle, l'important est de savoir si on peut avoir un code fonctionnel sans appel récursif quand un malloc() n'est pas free-é.

Si la réponse est négative, on peut laisser tomber. Mais très souvent dans la vraie vie, elle sera positive. Il suffit de ne pas placer par habitude les allocations trop tôt et les libérations trop tard. Si plusieurs blocs doivent être alloués en même temps, il faut faire la manip pour chacun de ces blocs.

L'idée est évidemment d'allouer un [ou plusieurs] bloc avant le premier appel, et de l'utiliser dans la fonction, le même donc pour chaque instance de la fonction.

Dans le cas le plus simple, la taille du bloc est la même quel que soit le contexte de l'instance. Ou on peut trouver simplemnt et sans hésitation un majorant de cette taille. Dans ce cas, il suffit d'allouer au départ, et d'ajouter le retour (adresse du bloc) aux paramètres de la fonction.

Un peu plus compliqué: on peut pifométrer un majorant raisonnable, mais avec la possiblité qu'une fois dans l'instance la taille allouée apparaisse insuffisante. Alors l'instance devra décider, à priori faire un free() suivi d'un malloc(), plutôt qu'un realloc(). Il faudra alors ajouter la taille du bloc aux paramètres de la fonction. Là, un petit souci apparait, très clairement si on griffonne le mécanisme d'appel récursif. En gros, l'adresse du bloc et sa taille reçues en paramètre ne seront plus nécessairement valides après un appel récursif. Il faut donc passer en paramètre non plus un void* (ou char*) et un entier, mais un pointeur vers un void* et un pointeur vers un entier. A charge pour l'instance qui réalloue de modifier les valeurs pointées. Plus compliqué à explique q'à faire.

(*) N'ayant pas trouvé d'autre mot, j'appelle "instance" ce qui est créé à chaque appel de la fonction. Une instance est donc vivante jusqu'à ce que le code retourne (return ou fin de la fonction). Elle est active quand elle est vivante et que le "code est dedans". Tant qu'une instance est vivante, elle possède son propre jeu de variables locales, copie des paramètres comprises.

Bonne journée,

Pierre

**nicolas.sitbon** · 28/12/2008, 11h45

Envoyé par Pierre Maurette

(*) N'ayant pas trouvé d'autre mot, j'appelle "instance" ce qui est créé à chaque appel de la fonction. Une instance est donc vivante jusqu'à ce que le code retourne (return ou fin de la fonction). Elle est active quand elle est vivante et que le "code est dedans". Tant qu'une instance est vivante, elle possède son propre jeu de variables locales, copie des paramètres comprises.

Bonjour, que dirais tu de "frame", je sais, le mot est anglais, d'un autre coté je pense que tout le monde le comprend.