Bonjour,
J’écris actuellement un programme en c++ et j'utilise l’allocation dynamique.
Je me suis amusé a regarder la mémoire prise par mon programe avec le gestionnaire des tache de windows.
Et la je m rend compte que lorsque je supprime mes objets, d’après le gestionnaire des tache de windows ma mémoire ne baisse pas.
Ce gestionnaire des taches est t'il fiable? Peut être que windows ne libère pas dessuite la mémoire?
Ou alors je me plante dans le code et je ne libere rien?
I faudrait voir ton code et la quantité de mémoire allouée et restituée.
Le code commence a être lourd je saurais pas trop quoi montrer.
J'utilise la librairie SMFL
Un petit exemple j'ai un objet qui fait environ 2K .
Lorsque je le crée l'objet en question des fois je ne vois pas la mémoire augmenter, des fois ça augmente d’environ 2K, des fois c'est plutôt 30K.
j'ai réussi a faire redescendre la mémoire en supprimant l'objet(pas toujours)
Mais j'ai du mal a comprendre la logique.
Je pense que la librairie utilise une partie de la mémoire que je ne soupçonne pas.
Autre chose je travaille avec codeblock et je compile en debug et non en relase. Ca vient peut être de la?
Après réflexion, ça n'a pas de sens. Ton application s'exécute au sein d'un processus. Or un processus possède ses propres ressources, comme la mémoire par exemple, et par conséquent sa propre pile, son propre tas. Comme tes variables dynamiques sont stockées dans le tas, ça ne change rien au niveau de la taille mémoire du processus.
Je ne comprend pas bien.
Que-ce qu'il na pas de sens?
Tu dis que le chiffre affiché dans le gestionnaire des taches ne représente pas la mémoire utilisé par mes variables?
De mesurer à l'aide du gestionnaire des tâches.Que-ce qu'il na pas de sens?
Exactement. Windows est un système multi taches. Comme je l'ai dit plus haut CHAQUE PROCESSUS POSSEDE SA PROPRE MEMOIRE, donc son propre tas.Tu dis que le chiffre affiché dans le gestionnaire des taches ne représente pas la mémoire utilisé par mes variables?
Il ne faut pas croire que quand tu fais un new xxx, windows va te donner quelques octets prélevés parmi les 4Go (ou plus) de ta mémoire. Si ton processus fait x Mo, y Mo sont affectés au tas et c'est là-dedans que tu vas taper pour tes variables dynamiques.
Ok,
Donc sa me rassure, je ne peux pas me fier a windows. Merci de tes lumières.
Une petite question pour ma culture, comment est définie la taille du processus?
C'est un peu exagéré. Disons que le gestionnaire des tâches fait ce qu'il a à faire: donner des indications sur les processus en cours.je ne peux pas me fier a windows
Je ne sais pas vraiment comment sont définies les règles configurant les espaces mémoire affectés à chaque processus. Il faudrait se plonger dans les arcanes du fonctionnement de l'OS, sans compter la gestion de la mémoire virtuelle, etc.Une petite question pour ma culture, comment est définie la taille du processus?
Quand on veut des mesures plus précises on utilise le perf. mon.; pas le gestionnaire de tâche qui n'a jamais été prévu pour cela.Envoyé par bastien31
C'est assez simple :
- L'OS alloue à ton process a un espace de mémoire virtuelle (un certain nombre de pages, donc), et ton process peut en demander plus.
- L'OS fait de la vente en gros. On fait pas un appel à l'OS pour chaque allocation d'un truc de 10 octets. Quand ton process a besoin de plus de RAM, il va demander un tas de pages en plus.
- malloc()/free() et new/delete découpent tout ça et font la vente au détail à ton code.
Plus spécifiquement, quand tu libères de la mémoire avec delete, tu as 2 cas:
- Soit tu libères un bon gros bloc constitué d'un certain nombre de pages, ou plein de petits blocs contigüs,
- Soit tu libères plein de petits blocs, mais il reste d'autres petits blocs toujours alloués qui se sont glissés entre.
Dans le premier cas, on a des pages libres, qui peuvent être rendues à l'OS et réutilisées par d'autres applis.
Dans le deuxième cas, toute page qui contient un bloc alloué, même de 8 octets, ne peut être rendue à l'OS. C'est la fragmentation mémoire.
On peut tout à fait prendre 4 Go de RAM avec 1 million d'objets de 8 octets, si chacun monopolise une page. Sauf dans les langages qui savent faire une garbage collection avec repacking, bien sûr.
Raison pour laquelle les programmes "serveur" propres (genre postgresql) gèrent leur propres malloc()/free()...
