MemoryError

[XanderLeaDaren]

Bonjour à tout le monde,

je continue le développement du script Python nous permettant d’avoir une interface NPİ / RPN graphique sous NumWorks (cf. ce sujet) et je tombe ce matin sur :

Last command
MemoryError:

Questions en vrac :
– s’agit-il de la taille du script, ou de l’espace mémoire nécessaire pour le faire tourner, qui est trop demandeur ?
– que puis-je faire pour réduire ce problème : optimiser les espaces/retours à la ligne/etc. ou optimiser le nombre de variables utilisées ?
– avez-vous des conseils pour cette optimisation ?
– éventuellement, si rien n’est franchement possible de faire pour améliorer l’ensemble, les intéressés par le script peuvent me faire savoir ce qui semble vraiment indispensable, ce qui peut être retiré, et voire même ce qui vous intéresserait dans les idées de développement que j’avais prévues, mais que je devrai laisser tomber ? (cf. issues sur GitHub de développement)

[critor]

Bonjour.


Si l'erreur se produit à l'exécution, c'est l'espace mémoire (le heap / tas) qui vient à manquer.

Le heap a une capacité dans les 64K sur le firmware officiel Epsilon.

Il faut optimiser : utiliser moins de variables, changer pour des types de variables moins gourmands en espace mémoire, stocker les données de façon plus optimale, etc.

[cent20]

Xavier ne l'ayant pas précisé mais me l'ayant expliqué sur des projets antérieur, je rajouterais que les objets qui changent de taille (manipulations sur les listes, .insert, .append) peuvent déclencher l'erreur quand on se rapproche de la taille limite.

[XanderLeaDaren]

Merci à tous les deux.

J’ai un peu épuré le code pour retirer des constantes, et des affectations à des variables de type string, gourmandes en mémoire, et j’ai remplacé quelques listes par des tuples là où c’était possible : typiquement du texte pour les menus, et j’arrive maintenant à pouvoir rajouter quelques fonctionnalités.

Par hasard, vous savez si charger le module ion en entier, avec toutes les constantes correspondants aux numéros des touches du clavier, est quelque chose qui surcharge la mémoire heap ? J’envisage de mettre des simples nombres dans les appels à keydown, si c’est le cas.

[cent20]

Merci à tous les deux.

J’ai un peu épuré le code pour retirer des constantes, et des affectations à des variables de type string, gourmandes en mémoire, et j’ai remplacé quelques listes par des tuples là où c’était possible : typiquement du texte pour les menus, et j’arrive maintenant à pouvoir rajouter quelques fonctionnalités.

Par hasard, vous savez si charger le module ion en entier, avec toutes les constantes correspondants aux numéros des touches du clavier, est quelque chose qui surcharge la mémoire heap ? J’envisage de mettre des simples nombres dans les appels à keydown, si c’est le cas.

Tout objet crée consomme de la mémoire. Tout est une question de compromis.
Une fonction lourde, longue, avec plein de paramètres va consommer plus qu'une fonction minimaliste. Parfois il est préférable d'avoir deux petites fonctions qu'une très grosse, mais si elle sont toutes les deux en mémoire ça consomme davantage.
Pour éviter les problèmes de mémoire je demande à mes élèves de :
- Ne pas utiliser de récursivité
- De faire des fonctions courtes, monotaches
- De vérifier qu'il n'y a pas des appels récursifs indirects
- De ne pas utiliser de POO, source de friction avec le collègue qui ne jure que par ça (mais quand ça plante c'est bibi qu'on vient voir, et bibi il refuse de corriger si il y a de la POO)
- De ne pas changer des types des objets, de ne pas les faire grossir
- De se limiter à des scripts de 16 Ko
- De ne pas créer de matrice géantes, même si mon dernier jeu utilise une matrice 32x20 et que tout tourne bien.

Bon débogage.