Architecture et fonctionnement de la mémoire

Bonjour à tous,

Imaginons qu'a chaque fois que je clique sur un bouton, un nouveau DIALOG s'ouvre. Dans le constructeur de se dialog j'ai le code suivant :

Code:

---

1 2 3

// m_szString est un WCHAR* membre de la class du Dialog m_szString = new WCHAR[100];

---

Et dans le destructeur de ce dialog :

Code:

---

1 2	delete [] m_szString;

---

Maintenant, j'aimerais savoir ce qui se passera si on fait affiche et ferme ce DIALOG plusieurs fois de suite. À priori il n'y aura pas de memory leak, cependant peut-il finir par y avoir de la fragmentation de mémoire au niveau du système ??? ((Biensur, d'autres opérations d'allocation et dé-allocation pourraient avoir lieu en même temps, et de tailles variables...)

Autrement dit, est-ce que Windows défragmente sa mémoire en idle ? Ou bien un moment où un autre il est voué à fragmenté à un point de ralentir le système...

Merci pour vos réponses

salut,
je ne pense pas qu'un tel mécanisme de défragmentation automatique existe...
maintenant je suis un peu étonné que ton cas conduise a un ralentissement du système.
tu devrais regarder les ressources utilisées par ton programme : objet gdi mémoire etc dans le gestionnaire de tache.

En fait je n'ai pas de ralentissement de mémoire, c'est plutôt une théorie.

Si cette théorie est juste alors il est fort probable qu'après de multiples allocation et dé-alocation de taille différente (voir des grosse allocation parfos) il puisse se créer des troues dans la mémoire et de ce fait, de la fragmentation.

Donc, après un certain temps, windows aura de plus en plus de difficulté à trouver de la mémoire libre pour allouer (bloc de mémoire conitnues), alors il puisera dans la mémoire virtuelle.

C'est que je développe sous "Windows CE", la mémoire est très limité et je me pose quelques questions à ce sujet. Cette application doit tourner 24h/24h, et elle ne doit en aucun cas souffir de ralentissement.

farscape : Pour m'assurer que je n'avais pas de memory Leak ou ressource leak, j'utilise le logiciel "Entrek Toolbox". Le BEST OF pour Windows CE. Bref, jusqu'ici, j'en ai aucun.

L'allocation fine fait via malloc n'est pas du ressort du système d'exploitation.
Windows n'alloue et ne libère que des pages mémoires de 4ko ou 4Mo.
C'est à la charge de la libc utilisé de faire sa tambouille pour la gestion fine de la mémoire.
Sur machine Intel utilisant une MMU (mémoire virtuelle), qu'un programme est beaucoup de page alloué ou pas, ça ne change rien. C'est les défauts de pages qui coutent chères.

Je ne suis pas sur de bien comprendre.

En résumé, est-ce qu'à long terme cela causera des problème ?

Prenons un autre exemple plus concret. Disons que dans une boucle sans fin, au début on alloue de la mémoire (taille variable à chaque fois) pour une chaine de texte et qu'à la fin on dé-alloue cette mémoire.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

srand ( time(NULL) ); BOOL bFinProgramme = FALSE; while (!bFinProgramme) { WCHAR szText = new WCHAR[ rand() % 500) + 1 ]; // Opération diverses... delete [] szText; // Autre allocation diverses ... new [?] delete [] ... }

---

Supposons que ce programme tourne durant 2-3 mois sans arrêt, que se passera-t-il dans la mémoire ? Y aura-t-il de la fragmentation, utilisation de la mémoire vituel un moment donnée ? Est-ce que libc s'organisera pour bien ré-organiser l'espace perdu et profiter de toute la mémoire ?

Au fait, qu'entend-on par LIBC ?

Merci pour votre aide, c'est apprécié.

En théorie (si on reste dans le théorique), une défragmentation automatique a lieu quand on libère la mémoire. C'est une chose importante à faire dans un gestionnaire mémoire pour éviter justement le problème d'une trop grande fragmentation...
Est-ce que CE le fait? Ben, fait un test d'endurance. Tu l'as déjà écrit!

le problème c'est que pour une application CE elle peut rester en permanence ouverte , le pb de la fragmentation se posera donc ici...
apparemment il est conseillé de travailler avec un tas (heap) séparé ,
voir HeapCreate ,HeapAlloc ,HeapFree, HeapRealloc ,HeapSize,HeapDestroy.

En fait l'application possède une trentaine de dialog chargé en mémoire. C'est au démarrage de l'application que tous ces dialog sont créés sur le heap. "new CDialog(..)".

Cependant, une seul fenêtre est visible à la fois (déterminé par la navigation client), celle-ci reçoit un message périodiquement (à toute les 200ms) lui demandant de rafraichir son contenu.

Dans la procédure rafraichissant le contenu, nous avons besoin d'envion de 4, 5 chaines de caractères de ~100 bytes. Ce qui totalise plus de 500 bytes.

Nous avons deux possibilités afin d'améliorer les performance :

1 - La première est de créer 5 chaines de 100 caractères sur le heap pour chaque dialog (au démarrage de l'application). Ensuite se servir de ces 5 chaines et libérer la mémoire qu'à la fin du programme. Lors de la destruction de toutes les dialog et la fermeture du programme. Ce que nous faisons actuellement.

2 - Créer ces 5 chaines local à la fonction de rafraichissement, donc sur la stack de cette fonction.

Bref, la solution 2 permet d'éviter tout tracas avec la défragmentation mais ralentira-t-elle les performances ?

Au fait, qu'elle est la taille de la stack pour une fonction ?

Merci pour votre aide :)