Discussion :

[scalpel]

Bonjour à tous,

Au stade actuel de mes connaissances, la question qui suit n'a pas trop d'importance. Mais par curiosité, je me demande tout de même si trier les lignes d'un très gros fichier texte en passant par une liste est une méthode acceptable. Les listes peuvent t'elles contenir une grosse quantité de données ?

[Sve@r]

Bonjour

Dans l'absolu, la mémoire est plus rapide que le disque. Donc oui trier en RAM ira plus vite. Mais il y aura le risque de "pas assez de RAM". En revanche, pourquoi passer par une liste ? with open(fichier, "r") as fp: data=tuple(sorted(fp)) et c'est réglé.

Sinon ici il y a un algo expliquant comment trier un fichier => https://miashs-www.u-ga.fr/prevert/P...usionFich.html.

[scalpel]

Je n'ai pas encore abordé les tuples
J'ai utilisé une liste pour résoudre un exercice du paragraphe "12-B-3 - Les listes sont des objets" traitant des listes

[Sve@r]

Je n'ai pas encore abordé les tuples

Ah oui c'est vrai, dans le Swinnen les tuples ne sont abordés qu'aux alentours de la page 150. J'ai jamais compris.
Ma façon de voir : en Python les tableaux se nomment des tuples. tab=("toto", "titi", "tata") c'est un tuple donc un tableau (accès via tab[x] avec "x" variant de 0 à 2 ; ou possibilité d'itérer via for item in tab). Le seul inconvénient c'est que tab n'est pas modifiable ; ce qui ne pose pas de souci si on veut juste le lire. Et dans le pire des cas, tu peux toujours le réécrire => rajouter "tutu" => tab=tab + tuple("tutu",).
Et si ensuite tu as besoin d'un tableau modifiable, là tu passes aux listes. Bref en fait les listes ne sont rien d'autre que des tuples modifiables.

Donc pour mon exemple, tu peux remplacer "tuple" par "list" et ça fait pareil. Sauf que si tu n'as pas besoin de modifier les datas, le tuple suffit. Surtout que les tuples peuvent être clefs de dictionnaires (ils sont immuables à condition qu'ils ne contiennent pas d'élément mutable) tandis que les listes (objets mutables par définition) ne le peuvent jamais... et que les tuples prennent moins de place que les listes.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
>>> tp=("toto", "titi", "tata")
>>> ll=list(tp)
>>> import sys
>>> sys.getsizeof(tp)
64
>>> sys.getsizeof(ll)
88
>>> from pympler import asizeof
>>> asizeof.asizeof(tp)
232
>>> asizeof.asizeof(ll)
256
>>> import pickle
>>> len(pickle.dumps(tp))
35
>>> len(pickle.dumps(ll))
37

Important : c'est la virgule qui fait le tuple, pas les parenthèses => tab="toto", "titi", "tata" c'est le même tuple (ce qui explique la virgule après le "tutu" ci-dessus). Mais je préfère mettre des parenthèses car je trouve ça plus lisible et quand Python affiche un tuple, il met aussi des parenthèses.

[papajoker]

bonjour

Les listes peuvent t'elles contenir une grosse quantité de données ?

Une liste (tuple, set, dict, ...) n'est qu'un conteneur ! Il faut donc comprendre qu'un conteneur n'a qu'une toute petite empreinte mémoire.
Ce qui compte, c'est uniquement le contenu

Il est très simple de voir ce que coute un conteneur en mémoire, cela dépend du nombre d'éléments

Pour tester la taille d'un conteneur (sans la taille des contenus)

Code :

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

1
2
3
4
5
6
7
8
import sys
 
conteneur = []
conteneur_s = []
for i in range(200):
    print(f"{i:4}:\t{sys.getsizeof(conteneur):5}  {sys.getsizeof(conteneur_s):5}")
    conteneur.append(i)
    conteneur_s.append("toto"*i)

Note:
- surprise la même taille pour les 2
- la valeur peut varier un peu en fonction de notre version de python et bien sûr en fonction de notre système, l'important est de voir que l'empreinte mémoire est négligeable même avec 200 éléments.
- on peut "voir" que l'incrément d'élément ne se fait pas un par un en mémoire mais par grappes (cela pour accélérer python)

Ta question donc dépend du contexte, pour être précis, du contenu et surtout de la ram disponible sur la machine. Avoir un tableau de plus de 1000 éléments n'a rien d'extraordinaire en python (si chaque élément ne fait pas 100Mo!)

les tuples prennent moins de place que les listes

En fait la différence est ici aussi très négligeable, il suffit de réécrire mon test avec des tuples
Sur ma machine : je passe de 920 à 840 octets pour 100 éléments. (Attention, différence variable car l'allocation mémoire du tuple n'est pas incrémentée par "grappe") Si je dois me soucier de quelques centaines d'octets, alors il serait bon d'abandonner python...
ps: l'accès à un élément d'un tuple est très légèrement plus rapide qu'une liste, mais ici aussi, différence très négligeable si on n'est pas dans une énorme boucle.

si trier les lignes ... en passant par une liste

En fait, on n'a pas le choix ! pour faire un tri il faut impérativement avoir tous les éléments en mémoire à un moment.

[scalpel]

Merci à vous deux pour ces explications très détaillées sur les tuples et plus largement les conteneurs.👌
J'ai tout compris, sauf les tests de Sve@r à partir de la ligne 8.

[wiztricks]

En fait, on n'a pas le choix ! pour faire un tri il faut impérativement avoir tous les éléments en mémoire à un moment.

Quand le coût mémoire était très cher, on savait trier un grand nombre d'items sans avoir à tout charger en mémoire. On avait même inventé des fichiers séquentiels indexés pour ça.

- W

[Sve@r]

J'ai tout compris, sauf les tests de Sve@r à partir de la ligne 8.

C'est juste un autre outil dédié au monitoring des objets Python

On avait même inventé des fichiers séquentiels indexés pour ça.

Oh là là je les avais complètement oubliés ceux-là, avec le organization indexed dans le file-control du COBOL...
Ceci dit, un index de table en bdd c'est quelque part aussi un équivalent...

[wiztricks]

Tant que les SGDB étaient propriétaires, l'organisation séquentielle indexée était plus économique pour de petites applications. Depuis qu'on a des SGDB open-source (et de la mémoire pas cher), on ne fait plus trop de séquentiel indexé.

- W

[papajoker]

J'ai tout compris, sauf les tests de Sve@r à partir de la ligne 8.

Sve@r utilise à partir de cette ligne une librairie externe pour voir en plus la taille du conteneur avec la taille du contenu en plus

Donc, tu as la mémoire occupée de "tout" alors que sys.getsizeof(), comme l'indique la doc, ne montre la taille en mémoire que de l'objet lui-même (ici, le conteneur).

[papajoker]

Petit complément, pour aller un peu plus loin, il est intéressant de comparer les empreintes mémoire des principaux conteneurs

Code :

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

1
2
3
4
5
6
7
8
9
count = 10_000
elements = [i for i in range(count)]  # liste de x elements
print(len(elements), "éléments")
print("list  ", sys.getsizeof(elements))
print("tuple ", sys.getsizeof(tuple(elements)))
print("dict ", sys.getsizeof({str(i):i for i in elements}), "[str,]")
print("dict ", sys.getsizeof({i:i for i in elements}), "[int,]")
print("set  ", sys.getsizeof(frozenset(elements)), "frozenset")
print("set  ", sys.getsizeof(set(elements)))

Résultat (en octets) sur ma machine avec 10 000 éléments

Code :

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

1
2
3
4
5
6
7
10000 éléments
list   85176
tuple  80040
dict  207616 [str,]
dict  294992 [int,]
set   524504 frozenset
set   524504

A noter:
- la différence de taille entre un dictionnaire indexé par un entier et le même indexé par une chaine : le gagnant n'est pas celui que l'on peut croire de prime abord. En fait, l'index entier est une duplication d'un index interne lui en chaine
- La taille d'un set ou frozenset (collection)

=============

Mais, en fait on ne va pas choisir d'utiliser un type de conteneur en fonction de l'empreinte mémoire Il est surtout bon de savoir que l'utilisation de list et tuple n'a pas d'incidence sur la RAM.

[scalpel]

Merci pour cet exemple très instructif pour moi. 👌

Mais du coup j'ai une question sur un de tes retours précédents que j'ai probablement mal compris.

... alors que sys.getsizeof(), comme l'indique la doc, ne montre la taille en mémoire que de l'objet lui-même (ici, le conteneur) ...

Pour qu'elle raison ce petit script me donne deux tailles différentes pour un même conteneur ?

Code :

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

1
2
3
4
5
6
import sys
liste1=['toto']
liste2=['toto','toto','toto','toto','toto','toto','toto','toto','toto','toto']
 
print("liste1 = ",sys.getsizeof(liste1))
print("liste2 = ",sys.getsizeof(liste2))

[papajoker]

Ce ne sont pas les mêmes "conteneurs", ce sont 2 conteneurs de même type (list) mais avec un nombre d'éléments différents
C'était non exemple 1

Code :

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

1
2
3
4
conteneur = []
for i in range(10):
    print(f"{i:4}:\t{sys.getsizeof(conteneur)")
    conteneur.append(i)

La taille est incrémentée en fonction du nombre d'éléments (quel que soit l'élément : type et taille).
ps: python incrémente la réserve mémoire par grappe (de 4) mais ce n'est que pour optimiser la vitesse

Tu peux te représenter un conteneur comme un tableau : une simple suite d'index

Code :

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

ma_liste -> reference1, reference2, reference3, ...

Dans ce schéma simpliste, on peut imaginer que le "tableau" utilise 2 octets de plus à chaque élément. Et puisque python est un peu plus complexe, il utilise un peu plus d'octets pour stocker une référence vers le contenu.

[Sve@r]

elements = [i for i in range(count)] # liste de x elements

elements=list(range(counts))

Mais du coup j'ai une question sur un de tes retours précédents que j'ai probablement mal compris.

Pour qu'elle raison ce petit script me donne deux tailles différentes pour un même conteneur ?

La remarque disant que les éléments n'importent pas sur la taille s'applique sur la nature du contenu. Une liste de 1000 petits ints pèsera pareil qu'une liste de 1000 très gros dictionnaires. Parce que la liste ne stocke pas vraiment les objets mais juste leurs positions mémoire.
C'est d'ailleurs la raison qui fait que si on duplique la liste même proprement, en recopiant soigneusement chaque élément qu'elle contient ; si on modifie un objet interne cette modification se retrouvera quand-même dans les deux listes malgré la copie propre

Code python :

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

1
2
3
4
5
6
7
8
>>> base=[1, 2, 3]
>>> orig=[base, base, base]
>>> copie=list(orig)
>>> orig.append("toto")
>>> orig
[[1, 2, 3], [1, 2, 3], [1, 2, 3], 'toto']
>>> copie
[[1, 2, 3], [1, 2, 3], [1, 2, 3]]

Jusque là ça va, "orig" et "copie" sont bien séparées. Mais continuons..

Code python :

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

1
2
3
4
5
6
>>> base.append("other")
>>> copie
[[1, 2, 3, 'other'], [1, 2, 3, 'other'], [1, 2, 3, 'other']]
>>> orig
[[1, 2, 3, 'other'], [1, 2, 3, 'other'], [1, 2, 3, 'other'], 'toto']
>>>

Et vlan !!! other se retrouve de partout !!!

Donc pour deux listes, la nature des objets qu'elle contient n'influe pas sur sa taille. Mais le nombre d'objets lui bien évidemment que ça a une influence !!!

liste1=['toto']

Quand tu crées une liste d'un seul élément, pense à rajouter la virgule. Pourquoi ? Pour être raccord avec la syntaxe "tuple". Pour une liste ce n'est pas obligatoire mais pour un tuple ça l'est donc en la mettant dans les deux cas, tu peux facilement changer sa nature sans avoir de souci.
Ecrire liste1=['toto',] te permettra de changer facilement en liste1=('toto',) sans risquer l'erreur. Tandis qu'écrire liste1=['toto'] t'imposera de te souvenir qu'il faut rajouter une virgule si tu veux le transformer en tuple.

[wiztricks]

Relisez vous:

Pour qu'elle raison ce petit script me donne deux tailles différentes pour un même conteneur ?

en quoi liste1 et liste2 sont-ils les mêmes? Ce sont deux listes qui contiennent un nombre d'objets différents... ce que reflète ce qui est retourné par getsizeof.

- W

[scalpel]

Avec la réponse de Sve@r, je viens de comprendre ma méprise.

... Une liste de 1000 petits ints pèsera pareil qu'une liste de 1000 très gros dictionnaires ...

Je n'avais pas compris que ce qui était important c'était le nombre d'objet dans la liste, pas leur poids.

Code :

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

1
2
3
4
5
6
import sys
liste1=[1,2,3,4,5,6,7,8,9,10,]
liste2=['toto','toto','toto','toto','toto','toto','toto','toto','toto','toto',]
 
print("liste1 = ",sys.getsizeof(liste1))
print("liste2 = ",sys.getsizeof(liste2))

Là j'ai le même poids.

Du coup, je comprends mieux l'intérêt de ceci :

>>> from pympler import asizeof
>>> asizeof.asizeof(tp)

Quand je me pose la question de l'impact d'une liste sur la mémoire de l'ordinateur.

[papajoker]

Quand je me pose la question de l'impact d'une liste sur la mémoire de l'ordinateur.

Python utilise beaucoup de mémoire pour chaque variable (par rapport à d'autres langages).
Donc, vu la faible empreinte mémoire d'une liste, tuple, en python, on considère qu'une liste n'a pas d'impact sur la mémoire ! Ce sont uniquement les éléments dans la liste qui compte (ce sont des variables classiques).

Un "conteneur" n'est qu'une facilité pour avoir accès à des variables, une facilité pour les gérer (ajout, supprimer, chercher, ...).

Dans le cas de ton exercice initial, tu peux considérer à la louche que la charge mémoire sera ta taille du fichier texte + un petit (5% ?) pourcentage.

[wiztricks]

C'est quoi çà?

Quand je me pose la question de l'impact d'une liste sur la mémoire de l'ordinateur.

Vous êtes parti d'un fichier à trier et une question non clairement posée côté peut-t-on charger le fichier sous la forme d'une liste de lignes pour le trier.

Il semble raisonnable de penser que cette possibilité dépendra du nombre d'octets du fichier et du nombre de lignes. Et intuitivement vous n'allez pas vous posez de question si le fichier "pèse" quelques Ko alors que vous allez réfléchir à deux fois lorsque ce sera plusieurs Go

Ces questions là ne dépendent pas trop du langage de programmation.
Il en est de même sur le comment "trier": si le fichier est "petit", la question sera "scolaire", si le fichier prend des plombe a être lu, il va falloir réfléchir côté algorithme pour que ça ait des chance de marcher (dans des délais raisonnables). Là aussi le langage de programmation aura une contribution espsilonesque

- W

[scalpel]

.... Vous êtes parti d'un fichier à trier et une question non clairement posée côté peut-t-on charger le fichier sous la forme d'une liste de lignes pour le trier. ...

Je sait bien qu'il est possible de trier un ficher en le chargeant dans une liste, car c'est exactement l'objet de l'exercice que j'ai effectué.
Dans l'ensemble de nos échanges il ne me semble pour pas m'être trop éloigné de ma question de départ.

Au stade actuel de mes connaissances, la question qui suit n'a pas trop d'importance. Mais par curiosité, je me demande tout de même si trier les lignes d'un très gros fichier texte en passant par une liste est une méthode acceptable. Les listes peuvent t'elles contenir une grosse quantité de données ?

Dans tous les cas, merci de vous intéresser à mes questions et de m'aider ainsi à avancer dans cet apprentissage.

[wiztricks]

Et bien si la question était:

je me demande tout de même si trier les lignes d'un très gros fichier texte en passant par une listetableau est une méthode acceptable

La réponse dépendra de la taille du fichier et de combien de temps attendre la fin du tri...
note: et je me suis permis de remplacer liste par "tableau" pour éviter de tomber dans l'aspect "langage python" du problème.

Pour ce qui est du langage Python, la limite sera la capacité mémoire que la machine pourra allouer à Python (ce qui se paramètre et sera aussi un arbitrage entre performance et dépassement de capacité).

- W