Allocation de mémoire : avantages/inconvénients - Page 1

Voilà, je voulais savoir quels sont d'après vous les avantages et les inconvénients d'allouer dynamiquement des tableaux de petites tailles qui sont très fréquements crée puis supprimer (dans le cas ou il est allouer) ?
Parce-que j'ai commencé un programme : formateur de texte avec un langage un peu particulier qui permet de faire des textes en niveau de gris et encore pleins d'autres choses et j'ai beaucoup de fonctions qui utilisent des tableaux pour rechercher dans les fichiers textes des paramètres, pour charger d'autres fichiers textes afin de "linker" des références, ou encore de créer de nouvelles chaîne de caractère avec un petit code.
Et je ne sais pas si il vaut bien allouer dynamiquement ces tableau ou utiliser simplement la mémoire du stack ?
D'ailleurs le stack, c'est quoi ? Parce-que je n'ai aucune idée de comment est réparti la mémoire.

Donc c'est quoi les avantages/inconvénient au niveau du temps d'accès à la mémoire, la consommation des piles, la rapidité (parce-que malloc() et free() doivent qd même prendre pas mal de temps et place ? ... Enfin pour la place je pense que j'ai la réponse ;D

Plutôt que d'allouer plein de petits tableaux, faits en un plus gros et défini en local si c'est possible, puisque l'inconvénient des fonctions d'allocations est qu'elle ne réussissent pas toujours (manque de mémoire par ex.).

Si les tableaux sont vraiments petits, tu ne peux pas en allouer à la taille maximum qu'ils pourront atteindre, et le laisser alloué pendant tout le programme ?

Si les tableaux sont vraiments petits, tu ne peux pas en allouer à la taille maximum qu'ils pourront atteindre, et le laisser alloué pendant tout le programme ?

Je le fais pour un tableau : celui qui stocke les balises, enfin les paramètres.
Mais j'ai une fonction sub_str qui retourne une chaîne dont le tableau est alloué dynamiquement et je ne sais pas si c'est bien d'utiliser un tableau "globale" ... surtout qu'après il faut faire un memset à chaque fois, non ? Ou le fait de mettre un caractère null permet de terminer la chaîne ?
Mais bon question rapidité ça ne me dérange pas trop : en fait c'est un peu comme si c'était le fichier text était compilé et pour l'instant c'est encore assez rapide.

Et je ne sais pas si il vaut bien allouer dynamiquement ces tableau ou utiliser simplement la mémoire du stack ? D'ailleurs le stack, c'est quoi ?

La pile, c'est l'endroit où sont stockées les variables locales de chaque fonction. Tu alloues ton tableau sur la pile si tu le déclares comme ceci :
char tableau[taille];
Dans ce cas il est automatiquement désalloué quand la fonction se termine (c'est une variable locale, quoi). Ça ne peut donc pas marcher a priori dans ton cas (tu ne peux en aucun cas retourner un pointeur vers ce type de tableau).
Sinon, c'est beaucoup plus simple quand c'est possible, mais il ne faut pas le faire avec de gros tableaux car la pile est limitée en taille (et si tu débordes ça plante tout).

le fait de mettre un caractère null permet de terminer la chaîne ?

Oui.

> Ou le fait de mettre un caractère null permet de terminer la chaîne ?
machaine[0]= 0;Bah si tu fais la chaîne est vidée

Ah d'accord merci. Mais c'est quoi la pile ? Parce-qu'il y a 16 ko, qd même, non ? C'est pas une partie de la RAM ? Elle se situe où physiquement cette mémoire ?

Ça ne peut donc pas marcher a priori dans ton cas (tu ne peux en aucun cas retourner un pointeur vers ce type de tableau).

Oui je sais.

il ne faut pas le faire avec de gros tableaux car la pile est limitée en taille (et si tu débordes ça plante tout).

Je le sais aussi.

Par contre j'avais entendu die que le fait d'utiliser des tableaux allouer dynamiquement consommait moins de pile... c'est vrai ?
En fait c'est ça qui pourrait être le plus intéressant.

la chaîne est vidée

Ah bon ?! Tout les caractères sont effacé ou c'est juste la chaîne qui est considéré comme vide ?
Parce-que pour les buffers vidéo par exemple il suffit par de faire ça pour les vider.

Non, la chaîne ne change pas, seul le premier caractère est modifié, mais comme toutes les routines considèrent le \0 comme la fin d'une chaîne, c'est comme si ta chaîne était vide.

La pile est une partie de la RAM, oui, et je ne sais pas exactement quelle taille elle fait.
Elle sert à mettre les variables locales des fonctions (bon pas seulement mais en gros c'est ça). Mais quand tu appelles une fonction, les variables de la fonction appelante restent sur la pile, tu n'as donc jamais toute la pile à ta disposition (sauf peut-être dans main (?)).

Par contre j'avais entendu die que le fait d'utiliser des tableaux allouer dynamiquement consommait moins de pile...

Oui, car la pile contient seulement un pointeur vers le tableau (et encore, pas forcément, ce pointeur peut être placé dans un registre) et non le tableau en entier.

Raphaël
: Ah d'accord merci. Mais c'est quoi la pile ? Parce-qu'il y a 16 ko, qd même, non ? C'est pas une partie de la RAM ? Elle se situe où physiquement cette mémoire ?

Elle utilise la RAM, ce n'est pas un composant à part. Le µP a besoin d'une zone de mem où il peut empiler des valeurs lors de sauts vers des sous-programmes par exemples.
Et on peut aussi l'utiliser pour stocker des données.

Par contre j'avais entendu die que le fait d'utiliser des tableaux allouer dynamiquement consommait moins de pile... c'est vrai ?

Oui puisque tu utilises une autre partie de la RAM que la pile (si tu alloues dynamiquement ça ne consomme rien sur la pile ! Ou alors à peine 4 octets si ton pointeur vers le bloc alloué est une var locale).

Sally Brown
: et encore, pas forcément, ce pointeur peut être placé dans un registre

Oué mais je crois que la place est quand même réservée quand GCC alloue une variable dans un registre. Ca ne prend pas plus de temps (toutes les variables sont réservées en une seule instruction).

Raphaël
: Elle se situe où physiquement cette mémoire ?

A début de la RAM. Au départ il y a 16 ko de pile, mais le TIOS et ton programme l'utilisent, donc y'a toujours moins.

Thibaut
:

Sally Brown
: et encore, pas forcément, ce pointeur peut être placé dans un registre

Oué mais je crois que la place est quand même réservée quand GCC alloue une variable dans un registre. Ca ne prend pas plus de temps (toutes les variables sont réservées en une seule instruction).

La place n'est pas forcément réservée, et ça peut parfois éviter complètement l'utilisation de variables locales sur la pile, ou porter cette utilisation en dessous des 8 octets maximum pour un subq. (Eh oui, -fomit-frame-pointer, ça existe...)

La place n'est pas forcément réservée

Même si on ne compile pas avec -fomit-frame-pointeur ?

Oui.
Si la variable peut être complètement éliminée ou complètement remplacée par un registre, il n'y a pas besoin de lui réserver un emplacement sur la pile, et le réserveur d'emplacements de la pile ne verra même pas le pseudo-registre correspondant à la variable. Et tu peux tester avec:

void f(void)
{
int a=ngetchx();
clrscr();
printf("%d",a);
}

, tu verras le link.w %a6,#0 indicateur d'un stack frame vide.