Page 1 sur 1
[R] Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 11:49
par Tetdoss
Salut à tous, je suis en train de découvrir ce merveilleux langage AutoIt et je me posais une question.
Y a-t-il des fuites de mémoire en AutoIt ? Car en fait je me demandais si c'était important de faire des _SoundClose ou encore des GUIDelete.
Selon moi, soit il faut penser à fermer ce que l'on a créé/ouvert préalablement ou alors ne rien faire car le langage est conçu pour ne pas faire manuellement les libérations de la mémoire.
Or dans tous les exemples que j'ai pu voir, on ne fait jamais de GUIDelete à la fin d'un programme GUI mais par contre on fait des _SoundClose

Alors dans quels cas il faut libérer la mémoire et dans quels cas il ne le faut pas ?
Est-il important de faire _SoundClose ou alors toutes les libérations sont faites automatiquement comme GUIDelete apparemment.
Voilà c'est tout, merci beaucoup d'avance

Re: [..]Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 11:57
par sylvanie
Bonjour
Et bien oui, il faut toujours penser à la fermeture des handle ouverts le plus possible.
Pour les GUI, on est souvent paresseux (et je me compte dans le lot), car souvent on n'en gère qu'une (voire deux), et lors de la fermeture du programme l'OS se charge de faire le ménage sur tout ce qui n'a pas été libéré par l'exécutable (ce qui est vrai sur tout type d'allocation, donc y compris les adresse d'allocation des sons, des images, mémoire en générale).
Mais dans l'absolu, si on faisait un programme qu'on ne ferme jamais et qui créer des fenêtres (ou des sons comme évoqué dans ce post, ou des contôles ... ), sans les libérer quand on n'en a plus besoins alors ça s'accumule à tout va et on prends de la ram pour rien ...
Re: [..]Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 12:08
par Tetdoss
Merci beaucoup de ta réponse très rapide sylvanie !
Donc OK je suis d'accord, il faut libérer quand on ne s'en sert plus mais si on s'en sert durant tout le programme jusqu'au Exit ? On peut laisser faire l'OS sans problème ?
Il ne peut pas rester des "résidus" de notre programme dans la RAM une fois le programme fermé ?
C'est surtout ça que je veux savoir car comme cela, si j'ai un programme avec seulement une GUI et un son (pendant tout le programme), je ne fais pas de GUIDelete ni de _SoundClose et si j'ai besoin de jouer un son seulement à un moment précis, alors là je penserais au _SoundClose.
Merci
Re: [..]Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 12:13
par TT22
Tetdoss a écrit :Il ne peut pas rester des "résidus" de notre programme dans la RAM une fois le programme fermé ?
Il est toujours possible qu'il en reste mais ce n'est pas très grave car la mémoire vive est vidée à chaque extinction du PC

Re: [..]Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 12:16
par sylvanie
Tetdoss a écrit :
Il ne peut pas rester des "résidus" de notre programme dans la RAM une fois le programme fermé ?
Non car le l'OS gère qui à réservé quoi, et donc si le process s'arrête alors tout ce qui lui était alloué est rincé.
Par contre je déborde un peu du sujet qui est dédier RAM pour avertir tout de même sur les utilisation de process externe (lors d'appels à un autre exe ou une dll). Là par contre on peut parfois arriver à des problématique de process orphelins qu'on peut parfois anticipé en concentrant toute les fermeture depuis le script "Père" via OnAutoItExitRegister appelé dans presque tous les cas (sauf arrêts violents (fermeture forcées, arrêt électriques mais là on n'a plus de soucis de fuite

) ...)
Re: [..]Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 12:19
par sylvanie
TT22 a écrit :Tetdoss a écrit :Il ne peut pas rester des "résidus" de notre programme dans la RAM une fois le programme fermé ?
Il est toujours possible qu'il en reste mais ce n'est pas très grave car la mémoire vive est vidée à chaque extinction du PC

Hummm c'est quand que tu passes en programmation sur serveur ou sur embarqué ?
En règle générale il faut toujours se dire que la machine peut tourner sans arrêt et ne pas miser sur son arrêt pour régler le problème.
Re: [..]Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 12:29
par Tetdoss
Parfait, merci tout le monde, je me posais la question car j'ai programmé plusieurs mois en C++ et il fallait toujours penser à libérer la mémoire avec les delete ! Les auteurs de tutoriels insistent en plus !
Ce que je ne comprends toujours pas car lorsque je regarde les performances du PC, avec ou sans delete, après la fermeture du programme, il y a toujours autant de mémoire vive libre.
Bref, je mets le [R]

Re: [..]Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 15:28
par jchd
Tetdoss a écrit :Parfait, merci tout le monde, je me posais la question car j'ai programmé plusieurs mois en C++ et il fallait toujours penser à libérer la mémoire avec les delete ! Les auteurs de tutoriels insistent en plus !
Ce que je ne comprends toujours pas car lorsque je regarde les performances du PC, avec ou sans delete, après la fermeture du programme, il y a toujours autant de mémoire vive libre.
Houlà, ce n'est pas pour la même raison, du tout. Quand on delete un _objet_ d'un langage OO, on invoque sa méthode delete, ce qui peut représenter un travail monstre, comme par exemple créer un fichier et écrire dedans deux tonnes d'infos vitales, imprimer la page de total d'un journal des ventes, mettre à jour une base de données, arrêter proprement une machine-outil, lancer un service, etc.
Tout ce travail doit être effectué dans un ordre bien précis qui correspond à une logique de fonctionnement que l'OS ne peut deviner et où il ne peut mettre ses gros sabots. Deleter un objet c'est donc invoquer une méthode éventuellement très complexe, puis libérer les ressources utilisées, ce qui peut signifier deleter des objets en cascade, etc. L'OS ne sait rien de tout ça : il déglingue tous les _blocs_ de mémoire alloués sans s'occuper de leur contenu et fait pareil pour les ressources, brutalement.
Re: [R] Les fuites de mémoire en AutoIt
Posté : mer. 16 nov. 2011 21:11
par Tetdoss
OK bien je comprends encore mieux maintenant, merci de l'info jchd