Discussion :

[Ange_blond]

Bonjour,

Je sais que le sujet a déjà été traité, mais j'ai des soucis de cohérence dans mes résultats depuis ce matin.

En gros, je traque les fuites mémoire. Pour celà, j'utilise le code suivant dans une méthode statique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
    DWORD pid = GetCurrentProcessId();
    //size_type result;
    HANDLE hProcess;
    PROCESS_MEMORY_COUNTERS pmc;
    hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,false,pid);
    if (GetProcessMemoryInfo( hProcess, &pmc, sizeof(pmc)))
    {
WorkingSetSize:
        result = pmc.WorkingSetSize; // memoire utilisé par le code
    }
    CloseHandle( hProcess );

Pour tester mon procédé, j'ai d'abord fait un test simple :

* getProcMemory
* malloc(1000*sizeof(double))
* getProcMemory

La différence de mémoire mesurée (en octets donc) est originale : 4096 octets
Si j'alloue 10000 double, j'ai une mémoire mesurée de 81920 ... (pas vraiment 10 fois plus)

En debug, j'ai 4096 octets de différence rien qu'en fesant

* getProcMemory
* getProcMemory

mais rien en Release (0 octets) !!

Je commence a douter sérieusement de GetProcessMemoryInfo() ... ou alors je l'utilise mal...
Faut il necessairement un process séparé ?
Y a t il des restrictions ?

Comment mesurer précisément la mémoire utilisée par le processus courant par une autre méthode sinon ?

Merci de votre aide.

Ange_blond

[bacelar]

<MSDN>
WorkingSetSize
The current working set size, in bytes.
</MSDN>

Vous confondez la mémoire utilisée et WorkingSet.
Enfin, mémoire utilisée c'est un peu vague. Ca veut dire quoi utilisée ?
-réservée en mémoire virtuelle ?
-adossé à une page physique de mémoire ?
-page swapé sur disque ?
-etc..

Le WorkingSet n'est que la taille de l'ensemble des pages physiques de mémoire attribuée à ce process. C'est la mise en swap d'une partie du code ou des données où leur retour en mémoire qui influence le plus cette taille.

C'est normal que votre workingSet ne suive pas votre allocation mémoire à la lettre.
Un malloc peu utilisé de la mémoire déjà utilisé précédemment et déjà libéré par votre code mais non restitué à l'OS.
Une partie de l'allocation n'est qu'une réservation de la plage d'adresse virtuelle dans l'espace d'adressage du programme. La récupération de la page physique se fera sur un défaut de page.
etc...

Gros WorkingSet, problème de localité du code ou des données.
"Petit" WorkingSet, programme correctement optimisé.

[Ange_blond]

Bonjour,

D'abord merci de votre réponse.

Vous confondez la mémoire utilisée et WorkingSet.
Enfin, mémoire utilisée c'est un peu vague. Ca veut dire quoi utilisée ?
-réservée en mémoire virtuelle ?
-adossé à une page physique de mémoire ?
-page swapé sur disque ?
-etc..

A vrai dire j'en sais rien... Je cherche a connaitre la taille de mémoire allouée par le processus, pour pouvoir faire les différence avant/apres création d'un objet et traquer les fuites mémoire.
Je n'ai pas de meilleure idée pour faire ça...


Je ne connais rien sur les pages, la gestion de la mémoire virtuelle et tout le reste... mais j'ai bien compris que je n'irai pas loin avec ma méthode.

Auriez vous peut etre une autre méthode a me proposer ?

Merci beaucoup :-)

[seeme]

Personnellement, j'utilise l'outil valgrind qui est simple à utiliser et donne les fuites mémoires (les erreurs d'allocations, de delete..).

C'est précis et efficace.

[Ange_blond]

Personnellement, j'utilise l'outil valgrind qui est simple à utiliser et donne les fuites mémoires (les erreurs d'allocations, de delete..).

J'en ai entendu parler oui, mais comme je suis sous windows...

[stardeath]

sous windows il y a visual leak detector, la crt (_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF )

après je ne sais pas si ça marche ailleurs que sous visual studio.