Gestion de la mémoire

Version imprimable

Bonjour à tous - Je viens ici demander une aide suite à un problème qui me turlupine. A force de chercher, j'ai réussi à ramener le problème à un exemple tout simple qui servira de démo facilement compréhensible

Je dois gérer un objet texte. A cet objet y vont s'adjoindre diverses méthodes me permettant de récupérer des infos sur ce texte comme nb lignes, de mots, etc.
A un moment donné, je dois renvoyer un paragraphe du texte. Je me dis en moi-même "un paragraphe étant un mini-texte, si je renvoie une nouvelle instance de mon objet ne contenant que ledit paragraphe, cette instance bénéficiera de toutes les méthodes utiles (nb de lignes, de mots, etc).

Mais c'est là que ça se corse. Voici un petit exemple tout simple montrant le problème. Pour simplifier, j'ai juste créé un objet qui stocke un tableau de nombres et créé une méthode "sort" qui renvoie un nouvel objet contenant le tableau trié
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 #!/usr/bin/env python # coding: Latin-1 -*- class cGestion: def __init__(self): print "init: %s" % repr(self) self.tab=[] def __del__(self): print "del: %s" % repr(self) del self.tab[:] del self.tab def __str__(self): return "[%s]: %s" % (repr(self), self.tab) def append(self, k): self.tab.append(k) def sort(self): n=cGestion() for k in self.tab: n.append(k) n.tab.sort() return n # Création élément de base base=cGestion() base.append(2) base.append(1) base.append(0) print "\nbase: ", base # Test 1: copie triée de l'objet de base - la copie est mémorisée cp=base.sort() print "\ntest 1:" , cp, cp.tab del cp # Test 2: affichage juste d'une instance triée print "\ntest 2:", base.sort() # Test 3: affichage d'un élément de l'instance triée print "\ntest 3:", base.sort().tab
A la base, je crée mon objet. Les affichages sont ok
Au test 1, je récupère une copie triée de mon objet. Aucun souci
Au test 2, j'affiche juste la copie triée de mon objet mais ne l'ai pas sauvegardée. Cependant aucun souci
Au test 3, là j'affiche le tableau stocké dans la copie au moment de la copie et là, je me rends compte que le destructeur a déjà fait son office et le tableau est vide.

Ce qui est intéressant, c'est que si dans le destructeur on supprime le nettoyage du tableau (del self.tab[:]), là tout marche bien. Je sais que Python possède une gestion de la mémoire et que je ne devrais pas me préoccuper de libération de mon tableau interne mais je suis issu du C et c'est plus fort que moi. Si mon constructeur crée un élément, mon destructeur supprime l'élément.

Quelqu'un aurait un conseil à me donner ?

Merci

19/03/2009, 13h45
dapounet

Bonjour,

C'est pas parce que tu del les int du tableau alors qu'ils sont encore référencés dans l'autre (et sûrement ailleurs) ?
19/03/2009, 14h44
shadowsam

Ouais, je viens de faire le test parce que je trouvais ca vraiment étrange et si on vire la ligne : del self.tab[:] il n'y a plus de problème.

Et alors même si cela fixe le problème, franchement je ne m'y attendais pas. D'ailleurs je ne comprends toujours pas pourquoi ca merde 8O Et la doc n'est pas très explicite sur ce comportement.
19/03/2009, 14h51
dapounet
Les int sont immutables, donc il n'y a pas de raison pour que l'interpréteur crée plusieurs objets qui représentent la même valeur.
C'est pour ça que ce code peut afficher True :
Code:

1 2 3 a = 1 b = 1 print a is b
Je crois qu'il faudrait utiliser del truc seulement si sys.getrefcount(truc) renvoie 1.

Le problème d'après moi est que même en c, tu n'aurais pas fais comme ça ;). Dans ton cas les objets n crées dans sort ne sont jamais détruit proprement.

Donc, le principe dans python est que tout élément qui n'est plus référencé (par une variable) est soumis à la gestion du garbage collector.

En C, j'aurais envisagé deux possibilités :

- Soit je laisse la gestion de la destruction de l'objet n dans la classe cGestion :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
class cGestion:
    def __init__(self):
        print "init: %s" % repr(self)
        self.tab=[]
        self.tabsort=[]
 
    def __del__(self):
        print "del: %s" % repr(self)
        del self.tab[:]
        del self.tab
        del self.tabsort
 
    def __str__(self):
        return "[%s]: %s" % (repr(self), self.tab)
 
    def append(self, k):
        self.tab.append(k)
 
    def sort(self):
        n=cGestion()
        for k in self.tab:
            n.append(k)
        n.tab.sort()
        self.tabsort.append(n)
        return n
 
# Création élément de base
base=cGestion()
base.append(2)
base.append(1)
base.append(0)
print "\nbase: ", base
 
# Test 1: copie triée de l'objet de base - la copie est mémorisée
cp=base.sort()
print "\ntest 1:" , cp, cp.tab
del cp
 
# Test 2: affichage juste d'une instance triée
print "\ntest 2:", base.sort()
 
# Test 3: affichage d'un élément de l'instance triée
print "\ntest 3:", base.sort().tab

- Soit c'est à l'appelant de gérer la durée de vie des objets que lui renvoient sort et :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
class cGestion:
    def __init__(self):
        print "init: %s" % repr(self)
        self.tab=[]
 
    def __del__(self):
        print "del: %s" % repr(self)
        del self.tab[:]
        del self.tab
 
    def __str__(self):
        return "[%s]: %s" % (repr(self), self.tab)
 
    def append(self, k):
        self.tab.append(k)
 
    def sort(self):
        n=cGestion()
        for k in self.tab:
            n.append(k)
        n.tab.sort()
        return n
 
# Création élément de base
base=cGestion()
base.append(2)
base.append(1)
base.append(0)
print "\nbase: ", base
 
# Test 3: affichage d'un élément de l'instance triée
n = base.sort()
print "\ntest 3:", n.tab
del n
 
del base

Avec

Code:

print "\ntest 3:", base.sort().tab

Tu crées une instance d'un objet qui n'est stocké nulle part, que tu ne pourras donc pas détruire, même en C, tu n'auras pas fais ça. En C, toujours, si tu appelles 500 fois xxx.sort(), tu auras 500 objets de crées qui ne seront jamais détruit, un beau memory leak ;)

#edit# Même si ça fais longtemps que je n'ai pas fais de c, je pense que ceci représente le même genre d'erreur :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// TestDel.cpp : définit le point d'entrée pour l'application console.
//
 
#include "stdafx.h"
#include <iostream>
using namespace std;
 
class Test {
    int a;
 
public:
    Test(int v);
    ~Test();
    int get();
    Test& sort();
};
 
Test::Test(int v) {
    a = v;
}
 
Test::~Test() {
    cout << "del : " << this << " : " << a << endl;
    a = 0;
}
 
int Test::get() {
    return a;
}
 
Test& Test::sort() {
    Test T(a+1);
    return T;
}
 
int _tmain(int argc, _TCHAR* argv[])
{
    Test T(1);
    cout << "T.a = " << T.get() << endl;
 
    cout << "T.a = " << T.sort().get() << endl;
    return 0;
}

Résultat :

Code:

1
2
3
4
5
E:\temp\TestDel\Debug>testdel
T.a = 1
del : 002EF974 : 2
T.a = -858993460
del : 002EFA74 : 1

Enfin, sur le principe, n'essaye pas de faire du python comme du C, ce n'est pas la même approche.

19/03/2009, 15h26
shadowsam
100% d'accord avec DelphiManiac. Il y une question de savoir qui a la responsabilité de la construction/destruction des objets.

Reste que ca ne m'explique pas le comportement précédent. Je suis d'accord avec toi, dapounet, les références présentes dans les listes 'pointent' ou référencent les mêmes objets en mémoire. Pas de soucis la dessus.
Mais del n'a jamais garantis l'effacement de l'objet mémoire. La fonction retire le lien entre la variable et l'objet mémoire, et seulement si le compte de référence passe a 0 alors l'object mémoire est effacé. DOC

Voici un autre test qui devrait poser un problème si l'explication simple était la bonne:
Code:

1 2 3 4 5 6 l1 = [1,2] l2 = [1,2] del l1[:] print l2
Non vraiment je n'arrive pas a voir ce qu'il se passe 8O Si quelqu'un a une vision plus claire a ce propos je suis preneur.
19/03/2009, 15h36
DelphiManiac
Le coup des int imutable, n'est d'après moi pas le problème, c'est juste une question d'économie de mémoire. Dans l'exemple de Dapounet, les 2 variables sont bien indépendantes :
Code:

1 2 3 4 5 6 7 8 9 10 11 #!/usr/bin/env python # -*- coding: utf-8 -*- a = 1 b = a # ou b = 1 print id(a), id(b),a ,b a = 0 print id(a), id(b),a, b print a is b
Même en changeant a, b garde sa valeur.

Si 2 variables (de type de base) ont la même valeur, python optimise la mémoire pour ne stocker qu'une valeur et faire pointer les 2 variables vers cette valeur. Ce n'est, d'après moi, qu'un question d'optimisation de mémoire.

Par contre dans le cas des listes, ce n'est pas pareil :
Code:

1 2 3 4 5 6 7 8 9 10 11 #!/usr/bin/env python # -*- coding: utf-8 -*- a = [1, 2] b = a print id(a), id(b), a, b a.append(3) print id(a), id(b), a, b print a is b
Ici a et b, pointe vers la même liste, le fais de faire a.append(3), ne crées pas une nouvelle liste, mais ajoute un élément à la liste existante (on travaille directement sur les valeurs de la liste) donc b pointe toujours vers le même emplacement que a.

Alors que :
Code:

1 2 3 4 5 6 7 8 9 10 11 #!/usr/bin/env python # -*- coding: utf-8 -*- a = [1, 2] b = a print id(a), id(b), a, b a = [2, 3] print id(a), id(b), a, b print a is b
crée une nouvelle liste (2, 3), qui ne se substitue pas à la liste existante, donc a != b à la fin.

@shadowsam

Ici, juste optimisation de mémoire.

Code:

1
2
3
4
5
6
7
8
9
10
 
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
l1 = [1,2]
l2 = [1,2]
 
del l1[:]
print l1
print l2

Ici, même liste :

Code:

1
2
3
4
5
6
7
8
9
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
l1 = [1,2]
l2 = l1
 
del l1[:]
print l1
print l2

19/03/2009, 16h42
kango

voici comment je comprends le test 3:

- dans la méthode sort, une nouvelle instance de cGestion est crée (elle est référencée une fois par n)
- la fonction sort retourne n
- comme aucune variable ne référence l'adresse de n, le ramasse miette intervient (il n'y a aucune référence à cette adresse dans le script principal, ce qui n'est pas le cas au test 2 puisqu'il y a base.sort())
- dans __del__ de cGestion, il y a 2 instructions: une qui déréférence les items de la liste (del self.tab[:]) et qui a pour conséquence de transformer self.tab en liste vide. la deuxième déréférence cette même liste (self.tab ne pointe plus dessus) mais la liste ne passe pas au ramasse miettes pour autant (car elle est pointé dans le script principal par base.sort().tab). Cette liste ne passe au garbage collector qu'après le print.

donc en gros:

- une instance de cGestion est crée dans sort
- elle passe au ramasse miette à la sortie de la fonction AVANT le print
- dans le __del__, del self.tab ne fait pas passer la liste pointée par self.tab au ramasse miette car une référence existe dans le script principal
- le print s'effectue
- la liste n'est plus référencé, elle passe au ramasse miette.

alors que dans le cas 2, la méthode __del__ de cGestion fait que la liste passe au ramasse miette avant la fin du __del__ de cGestion, et ceci, APRES le print.

pour vous en convaincre, créer une classe dérivée de list et surchargez la méthode __del__ :)
19/03/2009, 17h00
shadowsam

Merci les gars pour les explications. J'étais arrivé à la même conclusion que toi, kango. Je pense que c'est effectivement ce qu'il se passe.

C'est vrai que cela est très logique compte tenu du système de gestion du GC même si l'on arrive à un comportement assez difficile a prévoir dans ce cas précis.
21/03/2009, 13h52
Sve@r

Citation:

Envoyé par DelphiManiac

Le problème d'après moi est que même en c, tu n'aurais pas fais comme ça ;). Dans ton cas les objets n crées dans sort ne sont jamais détruit proprement.

Arf t'as tout à fait raison. C'est vrai qu'en C (ou C++), sachant que c'est à moi de gérer, j'aurais fait gaffe à ne pas créer d'instance d'objet non référencée. Mais comme Python est un peu nouveau pour moi, je tombe dans le travers d'utiliser des techniques Python quand je les découvre (renvoyer une liste, un objet, etc) et quand je suis perdu de retomber dans mes habitudes C => d'où ce beau mélange assez horrible

Citation:

Envoyé par DelphiManiac

Enfin, sur le principe, n'essaye pas de faire du python comme du C, ce n'est pas la même approche.

T'as raison. En fait, faut pas que je me fasse ch... à penser à ma mémoire. Le gc s'en charge tout seul et mieux que moi c'est ça ???

Citation:

Envoyé par kango

voici comment je comprends le test 3:

- dans la méthode sort, une nouvelle instance de cGestion est crée (elle est référencée une fois par n)
- la fonction sort retourne n
- comme aucune variable ne référence l'adresse de n, le ramasse miette intervient (il n'y a aucune référence à cette adresse dans le script principal, ce qui n'est pas le cas au test 2 puisqu'il y a base.sort())
- dans __del__ de cGestion, il y a 2 instructions: une qui déréférence les items de la liste (del self.tab[:]) et qui a pour conséquence de transformer self.tab en liste vide. la deuxième déréférence cette même liste (self.tab ne pointe plus dessus) mais la liste ne passe pas au ramasse miettes pour autant (car elle est pointé dans le script principal par base.sort().tab). Cette liste ne passe au garbage collector qu'après le print.

donc en gros:

- une instance de cGestion est crée dans sort
- elle passe au ramasse miette à la sortie de la fonction AVANT le print
- dans le __del__, del self.tab ne fait pas passer la liste pointée par self.tab au ramasse miette car une référence existe dans le script principal
- le print s'effectue
- la liste n'est plus référencé, elle passe au ramasse miette.

alors que dans le cas 2, la méthode __del__ de cGestion fait que la liste passe au ramasse miette avant la fin du __del__ de cGestion, et ceci, APRES le print.

pour vous en convaincre, créer une classe dérivée de list et surchargez la méthode __del__ :)

Merci pour cette explication très claire et très détaillée et à tous les intervenants

Bon, je décide de virer toutes mes méthodes __del__ et de faire confiance au gc. J'espère ne pas le regretter (style j'appelle base.sort() dans une boucle de 50000 itérations et le gc n'intervenant pas immédiatement j'obtiens un superbe crash mémory)
25/03/2009, 10h37
Thierry Chappuis

Tu peux toujours demander au ramasse-miettes de faire emplettes en appelant gc.collect(). Sauf erreur de ma part, le ramasse-miette est essentiellement là pour gérer les problèmes de références cycliques. La plupart du temps, lorsqu'un objet voit son compteur de références arriver sur 0, la mémoire est immédiatement libérée, et donc ta boucle de 50000 itérations ne devrait pas causer de soucis. Du moins, c'est comme ça je le comprends, mais j'avoue ne pas m'être beaucoup intéressé au modèle de gestion de la mémoire par python. Si quelqu'un à des références plus précises à ce sujet, je suis intéressé.

EDIT: ce blog va dans le sens de ce que j'avance plus haut. La libération des ressources est déterministe, sauf cas particuliers.

Thierry