Dans ton cas, tu ne vas pas construire ta grande liste de petites liste en une fois, mais simplement tes petites listes au fur et à mesure que tu lis chaque ligne. Parfois cela impliquera de refaire un calcul (pour recommencer au début du fichier f, faire f.seek(0,SEEK_SET) cf. documentation), mais c'est un compromis nécessaire quand tu travailles avec de grosses données. Voir aussi la notion de fold/reduce pour le big-data, les algos pour calculer des moyennes cumulées, etc.
pr le swap, tu parles bien d'un reglage de l'os?
Oui cela permet d'augmenter virtuellement la mémoire disponible pour un programme au prix de très mauvaises performances, voir de problèmes de stabilité pour les autres programmes, à éviter donc. C'est défini par la taille de ta partition d'échange ou de fichier swap supplémentaires (comme sur windows). Dans ton cas, tu peux voir ton fichier comme un swap, c'est-à-dire de la mémoire stockée sur disque et chargée à la demande, pas besoin de le charger deux fois en "mémoire" donc.
je n'ai pas vu de doc sur le calcul de la memoire necessaire
Il ne s'agit pas de faire un calcul précis mais juste une approximation, bien que comme tu as l'air d'en être au courant avec beaucoup de recherche sur les types de datastructures utilisée par python il doit être possible d'être assez précis. Genre comptons au pif 10 octets par entiers, 16 octets d'overhead de la liste par valeur d'entier (2 pointeurs ?), 100 pour par liste en elle même (entête, stats, ref gc, etc. ??). et que dans ton fichier original tu utilise en moyenne 3 octets par valeurs, ca te fais 800*1M/3*26+100*2 octets, fin bref grosso-modo un facteur*10 en python... Bien sûr à cela tu vas devoir ajouter la mémoire utilisée pour faire ton traitement et tes résultas intermédiare, sauf si c'est négligeable (exemple: pour calculer la moyenne il te faut juste stocker une somme et un compte).
[^] # Re: Moteur SQL
Posté par benja . En réponse au message "Processus arrêté". Évalué à 3. Dernière modification le 09 octobre 2020 à 16:09.
Oui c'est exactement ça dont je parle, il y a un tuto ici https://realpython.com/introduction-to-python-generators/#example-1-reading-large-files
Dans ton cas, tu ne vas pas construire ta grande liste de petites liste en une fois, mais simplement tes petites listes au fur et à mesure que tu lis chaque ligne. Parfois cela impliquera de refaire un calcul (pour recommencer au début du fichier f, faire f.seek(0,SEEK_SET) cf. documentation), mais c'est un compromis nécessaire quand tu travailles avec de grosses données. Voir aussi la notion de fold/reduce pour le big-data, les algos pour calculer des moyennes cumulées, etc.
Oui cela permet d'augmenter virtuellement la mémoire disponible pour un programme au prix de très mauvaises performances, voir de problèmes de stabilité pour les autres programmes, à éviter donc. C'est défini par la taille de ta partition d'échange ou de fichier swap supplémentaires (comme sur windows). Dans ton cas, tu peux voir ton fichier comme un swap, c'est-à-dire de la mémoire stockée sur disque et chargée à la demande, pas besoin de le charger deux fois en "mémoire" donc.
Il ne s'agit pas de faire un calcul précis mais juste une approximation, bien que comme tu as l'air d'en être au courant avec beaucoup de recherche sur les types de datastructures utilisée par python il doit être possible d'être assez précis. Genre comptons au pif 10 octets par entiers, 16 octets d'overhead de la liste par valeur d'entier (2 pointeurs ?), 100 pour par liste en elle même (entête, stats, ref gc, etc. ??). et que dans ton fichier original tu utilise en moyenne 3 octets par valeurs, ca te fais 800*1M/3*26+100*2 octets, fin bref grosso-modo un facteur*10 en python... Bien sûr à cela tu vas devoir ajouter la mémoire utilisée pour faire ton traitement et tes résultas intermédiare, sauf si c'est négligeable (exemple: pour calculer la moyenne il te faut juste stocker une somme et un compte).