Discussion :

[Pistolero_JB]

Bonjour a tous,

c'est mon premier post ici,

j'ai une bizarrerie sur python et je ne vois pas pourquoi et comment gerer ca. Quelques mots sur le contexte, je charges en memoire (dans une variable python) un fichier volumineux ~5Go (liste de donnee provenant d'une matrice de 28805x28805 elements). Bref, mon probleme est dans le chargement du fichier dans la variable, par exemple si j'execute ce code:

Code :

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

1
2
3
4
5
n    = 100000000
data = [0.0] * n
val  = 1.25e+02
for i in xrange(n):
    data[n] = val

quand j'alloue de la memoire pour la variable, j'utilise ~ 740 Mo, et lorsque la boucle tourne pour remplir la variable data la mémoire reste constante car allouer au debut. Maintenant si j'execute ceci:

Code :

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

1
2
3
4
5
6
7
from string import atof
 
n    = 100000000
data = [0.0] * n
val  = '1.25e+02'
for i in xrange(n):
    data[n] = atof(val)

la memoire utiliser au depart est de 740 Mo a l'allocation puis ne cesse d'augmenter pendant ma boucle pour atteindre les 3.9 Go. Je penses que le probleme est que atof me retourne un flottant different du flottant utilise en allocation... qu'elle est le probleme... comment convertir ma chaine de caractere en flottant 32 bit.

Une suggestion ?

Merci

[Matthieu Brucher]

Bizarre.

Déjà, le module string est déprécié. Tu as essayé avec :

Code :

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

1
2
3
4
5
n    = 100000000
data = [0.0] * n
val  = '1.25e+02'
for i in xrange(n):
    data[n] = float(val)

?

Et pour des données aussi importantes, tu devrais passer à Numpy

[Pistolero_JB]

Le probleme est identique avec float(), la solution numpy je l'utilise actuellement en attendant, car quand j'alloue une variable array de type float 32 bit, la memoire reste constante. Le probleme avec ma variable array, c'est que j'ai remarque un ralentissement sur le temp d'acces des donnees, et donc un ralentissement de l'algo... ralentissement constater mais non evaluer, pas encore.

Effectivement, c'est tres bizarre...

[Matthieu Brucher]

Louche. Essaie de chopper le nombre de références en cours (je ne sais plus quelle est la fonction dans sys, mais ça devrait donner une indication).

[yacinechaouche]

Rien de nouveau : soit le programme utilise moins de mémoire, mais est plus lent, soit il utilise plus de mémoire et il est plus rapide. C'est très difficile d'avoir les deux en même temps.

[Matthieu Brucher]

Les deux programmes travaillent sur des listes de même taille, et à chaque fois un seul élément est modifié. Ta remarque est donc complètement à côté du problème.

[yacinechaouche]

...la solution numpy je l'utilise actuellement en attendant, car quand j'alloue une variable array de type float 32 bit, la memoire reste constante. Le probleme avec ma variable array, c'est que j'ai remarque un ralentissement...

Oups pardon. Mais j'ai cru lire qu'avec numpy il n'y avait pas de problème de mémoire, vu que numpy utilise des tableaux C, mais des problèmes de lenteurs.

Les deux autres solutions utilisent des listes et non des tableaux. Dans un cas, des floats sont directement injectés et la mémoire reste constante, dans l'autre, des chaînes sont converties en float et là la mémoire augmente.

J'en conclu donc :

• utilisation de numpy => temps plus lent mais pas de prob de mémoire.
• utilisation de listes pythons => pas de prob de temps mais problèmes de mémoire à la conversion des float.

J'ai bon là ?

[Matthieu Brucher]

Non, c'est lors de l'utilisation de la fonction float() ou atof() qu'il y a une fuite mémoire. Peut-être.

[yacinechaouche]

C'est ce que j'entendais par conversion de float.