Allouer de la mémoire pour un tableau en plusieurs fois. - Page 1

Bon voilà je me suis remis à FTL VIEWER et je voudrais réduire considérablement la mémoire allouée par mon programme.
Je vais d'abord situer le problème :
Je rapelle que FTL VIEWER est un viewer de texte qui interprète un langage à partir d'un fichier TEXT.
Voici le structure du tableau qui va servir à stoquer les données à afficher. Chaque ligne de ce tableau correspond soit à une image , soit une ligne de texte.

typedef struct
{
unsigned char flag;
union
{
BMP Bmp;
TEXT Text;
}File;

}DOCUMENT;

Mais le nombre de ligne de ce tableau n'est pas connu à l'avance. Tout se met en place lors du parsing effectué qu'une seul fois lors de l'ouverture du document.
Donc pour ne pas prendre de risque j'alloue un nombre maximum de ligne au départ :

DOCUMENT *Document=Malloc(2048*sizeof(DOCUMENT));
Et ensuite lors du parsing j'alloue la mémoire pour le texte et les images en fonctions des besoin.

Grossomodo pour chaque document mon programme bouffe 31 ko de RAM tandis qu'un document de 100 ligne prendrait 11 ko tout au plus.

Donc je me demandais s'il était possible d'allouer le tableau au fur et à mesure, comme le contenu. Je n'ai pas essayé avec Realloc mais je pense que ça serait un peu lourd.

rien ne t'empeche d'allouer à (tableau+taille_de_allouée )

Euh je ne vois pas bien ce que tu veux dire là ?

Si tu ne veux pas allouer le maximum de mémoire que tu pourrais allouer, tu n'as pas vraiment le choix, tu es obligé d'utiliser realloc... Je ne vois pas en quoi ça serait lourd ? (à part qu'il faut appeler une fonction à chaque fois que tu veux rajouter un élément pour vérifier qu'il y a assez de place dans le buffer alloué, et sinon l'agrandir un peu)

Je ne vois pas en quoi ça serait lourd ? (à part qu'il faut appeler une fonction à chaque fois que tu veux rajouter un élément pour vérifier qu'il y a assez de place dans le buffer alloué, et sinon l'agrandir un peu)

Mouais mais alors je ne vais pas allouer de la mémoire toutes les lignes mais plutôt tout les 100. Comme je fais avec malloc (j'alloue des blocs de 1 ko et je met toutes les données bout à bout).
Bon, bah si c'est la seule solution, je ne vais pas chercher plus loin. Merci !

Il y a un truc bizarre là !
J'alloue donc de la mméoire à chaque nouvelle ligne :
nb_str++;
Document=realloc(&Document,(nb_str+1)*sizeof(DOCUMENT));

Mais à la fin il ne faut surtourt pas que je libère la mémoire. Si je fais fre(Document) ou free(&Document) ça plante.
Et apparement il n'y a pas de mémoire perdu... je n'y comprend plus rien !

Euh si en fait il y a un tout petit eu de mémoire qui se perd. Il faut faire comment pour libérer un bloc de mémoire realloué ?

Pourquoi tu passes &Document à la fonction realloc ?

oui, ton pb doit être lié à ce qui dit sasume, et tu n'es pas obligé de réallouer à chaque fois : il suffit que tu augmentes un peu la taille de ton bloc mémoire qd tu l'augmentes (plusieurs ko) et que tu stockes la taille dans une variable pour savoir qd il y a besoin de faire un realloc...

Oui je le fais pour les malloc. Mais déjà si ça ne marche en le faisant toutes les lignes je ne vois pas comment ça va marcher avec un bloc.
Sinon c'est ça qu'il faut que je fasse : "Document=realloc(NULL,(nb_str+1)*sizeof(DOCUMENT));" Parce-que ça ne marche pas du tout.
Le seul truc qui marche c'est de mettre le tableau en argument. Et puis mon programme et très complexe alors je ne sais pas trop d'où proviennent les crash.
Et puis je suis obligé de faire un realloc pour ma première ligne. Si je laisse juste le malloc elle ne s'affiche pas.
Et enfin je ne comprends toujours pas comment une grosse partie de la mémoire se libère toute seule sans faire un free().
Quand je le fais c'est toujours pareil, ça plante !

Edit: j'alloue maintenant tout les 10 lignes et ça marche mais impossible de libérer la mémoire sans crash !

C'est bon, plus la peine de répondre j'ai réussi à faire marché tout ça.
Mais par contre j'aurais une question : HeapAlloc alloue e la mémoire au même titre que malloc ?
Parce-que dans mon programme je calcule la quantité de mémoire précise allouée par tout mon programme afin que l'utilisateur connaisse pour chaque fichier la mémoire que va alloué FTL VIEWER.

"au même titre" = ???

Euh oui excusez moi je me suis mal exprimer Je vais faire plus simple : c'est quoi la différence entre heapalloc et malloc ?
Parce-que j'utilise la lib TinyX pour gérer les fonts et Neuroo utilise Heapalloc pour sauvegarder et HeapFree() pour les libérer mais je ne comprends pas pourquoi il utilise ses fonctions à la place de malloc et free.

Tu as pensé à aller voir la doc de tigcc à ce sujet ?

Oui évidement.
Voilà :

HANDLE HeapAlloc (unsigned long Size);


Allocates memory and returns a handle of allocated block.

HeapAlloc allocates a block of heap memory of Size bytes (all odd sizes are rounded up to be even) and returns its handle. Allocated blocks are kept in a singly-linked list of blocks. Returns H_NULL if there is not enough memory. The maximum size of a single block is 65520 bytes, and the minimum size is 6 bytes. Use HeapDeref to dereference the handle and get a pointer to the actual memory. Note that an unlocked pointer to the heap is valid only as long as heap compression (i.e. garbage collection) is not done. This routine may cause garbage collection.

Mais justement je ne sais pas ce que c'est que la heap memory. De toute manière ça diminue sûrement la RAM comme avec malloc.
Et puis GraphX, par exemple dispose de sa propre font (celle de Einstein). Il me semble que la mémoire est prise sur la pile et je ne sais pas si je dois la compter dans la mémoire que prend le programme.
Pou l'instant mon programme prend 17 ko pour un petit texte sans compter la Font de GraphX.

La heap memory, c'est la mémoire disponible dans le "tas", c'est à dire en RAM.

HeapAlloc / HeapFree travaille avec des handles.
malloc / free travaille avec des pointeurs sur le premier element de la zone allouee.

Tu peux passer des handles aux pointeurs via HeapDeref ou HeapPtrToHandle.

En gros, travailler avec des ptr est plus simple, mais a un inconvenient : on doit verouiller la zone memoire pour eviter qu'elle ne se deplace en memoire
suite a un Garbage Collector. Avec les handles, la zone memoire reelle peut bouger mais tu y accedes via HeapDeref, donc chaque fois tu prends la
vraie valeur du pointeur vers la zone memoire.
En gros un handle c'est un indice dans la table des zones memoires allouees par AMS.
Un ptr (retournee par malloc) est la valeur d'un des elements de cette table.
Mais le systeme doit rajouter quelques infos en plus dans la zone de memoire si tu travailles avec les ptr,
donc tu ne peux pas directement passer d'un systeme base sur HeapAlloc a un systeme base sur malloc.
Ne melange pas les deux systemes (ie si c'est allouee avec HeapAlloc, libere avec HeapFree, et reciproquement), et ca ira tres bien. Sache juste que malloc est une surcouche de HeapAlloc (car elle doit verouiller la zone memoire pour eviter qu'elle ne se deplace).

J'aime bien pouvoir bloquer un handle qui va être utiliser tout au long d'un programme....

Oui. Et tu veux savoir le faire ?

(heu ... c pour lui dire pkoi j'utilise ça pour tinyx)

Cf http://tigcc.ticalc.org/doc/alloc.html#HeapLock et http://tigcc.ticalc.org/doc/alloc.html#HeapUnlock
pour locker / delocker un handle.

Raphaël
: Mais justement je ne sais pas ce que c'est que la heap memory.

!!! Tu programmes depuis combien de temps sur TI? 2 ans? On voit bien les dégats que fait genlib...

Et Kevin se permet de m'appeller Monsieur Troll. Le pauvre.

Raphaël : La police d'Einstein et de GraphX est enregistrée dans la RAM, avec le programme. Ma fonction ne stocke rien dans la pile si je me souviens bien (à part les adresses de retour des sauts, ça on n'y peut rien ).

Raphaël : La police d'Einstein et de GraphX est enregistrée dans la RAM, avec le programme. Ma fonction ne stocke rien dans la pile si je me souviens bien (à part les adresses de retour des sauts, ça on n'y peut rien).

Ah oui c'est vrai ! Ok, donc ça fait déjà ça de moins.

Tu programmes depuis combien de temps sur TI? 2 ans? On voit bien les dégats que fait genlib...

Oui je ne sais plus... peut-être bien oui. C'est bien tu le sais mieux que moi ! Un peu plus parce-que avant le C je programmais sur Ti 83+ en BASIC.
Mais avec TIGCC, 2 ans.

Alors déjà je ne programme pas avec Genlib du tout (bien que ce soit une très bonne lib : je ne vois pas pourquoi elle ferait des dégâts d'ailleurs ) sauf pour mon moteur 3D que j'avais passé sous Genlib pour les bsp mais j'ai abandonné et puis sinon je programme par période, pendant les vacances, à raisons de quelques heures maximum par jours, les seuls jours où je programme : des fois c'est 2 minutes.
Et puis cet année je suis sur le viewer de texte et je passe mon temps à optimiser, bencher des routines, corriger des bugs, réduire la taille du programme, réduire la conso des piles, la mémoire alloué par le programme... et là je vais m'intéresser à la stabilité du programme parce-que pour le moment c'est pas génial.
Donc je n'apprends pas grand chose.
Et puis autant il y a des fonctions que j'utilise tout le temps comme malloc autant je ne me suis jamais intéressé à HeapAlloc.
Même realloc, jusqu'à mainteant j'en avais jamais eu besoin.
C'est vrai que je ne devrais pas avoir d'excuse compte tenu de l'excellente documentation de TIGCC (il n'y a rien à en dire) mais bon quand je programme, ça ne me vient pas à l'idée comme ça d'utiliser cette fonction.

Je dis que genlib fait des dégâts parce qu'elle te cache toutes les bases de la programmation comme justement le heap. Mais bon, dans ton cas, je me suis trompé, le problème est ailleurs. À mon avis, il faudrait se renseigner un minimum sur la gestion de la mémoire de AMS avant de se lancer dans de gros projets. Parce que sinon, on risque d'utiliser plein de structures de données totalement inadaptées à la plateforme (listes chaînées etc.).

N'importe quoi...
GrayOn aussi alors puisque la fonction alloue elle-même les planes (d'ailleurs ça cause des inflexibilités), ça cache donc cette partie de la programmation...

Et puis genlib propose des fonctions pour allouer sur la pile, par opposition à l'allocation sur le tas, donc elle ne cache rien du tout...

Franchement ta haine contre genlib vient d'ailleurs, pas de là...

[edit] Et je viens de regarder la doc, genlib propose également des fonctions pour gérer les handles (gl_push_hd, gl_pop_hd) récupérés avec les fonctions d'allocation du style HeapAlloc, donc vraiment tu racontes n'importe quoi (et je me fous que tu ne sois pas français).

Kevin> la prochaine fois réfléchis avant de lancer un troll aussi démeusuré et stupide qu'hors sujet, merci, ça aide pas ...

>Je dis que genlib fait des dégâts parce qu'elle te cache toutes les bases de la programmation comme justement le heap.

Trop, trop fort ! Allez encore une fois, Kevin, s'il te plait. Ca fait longtemps que je me suis pas tant marre.
Merci beaucoup, ca fait du bien de pleurer de rire.