optimisation de la mémoire occupée

Question

Bonjour à tous ! 

Je voudrais essayer d'optimiser la mémoire qu'occupe un de mes programme en ram (car il est censé être exécuté en permanence en arrière plan).
Je me suis apercu que par exemple à partir du moment où l'on ouvre une boite de dialogue pour ouvrir un fichier (opendialog) la place occupée en mémoire augmente mais cette place ne diminue pas lorsque l'on referme la boite de dialogue. Idem quand on utilise la fonction URLDownloadToFile, etc...

Existe-t-il un moyen simple de décharger ce qui a été chargé pour ouvrir une boite de dialogue ou pour l'execution d'un fonction ?

me suis-je bien fait comprendre ? 

merci d'avance

fred

florenth · Answer

Je ne suis pas sur de ce que je vais dire mais il me semble que la VCL a des fuites de mémoire.
D'après MemProof, ce que tu affirme est confirmé, mais la place mémoire augmente une fois pour toutes (elle n'augmente pas à chaque TOpenDialog ouvert)

Pour décharger, c'est pas forcément évident.
Sur le moment, je ne vois pas mais comme j'ai le mêm soucis que toi, j'y réflechis et je t'en parle si je trouve.

@ ++ et bonne chance ...
Florent

Si tu ne te plantes pas ......
tu ne pousseras jamais

DeltaFX · Answer

Florenth, aurais-tu une doc de memProof qui soit en phase avec la derniere version (delphi7), J'ai tenté de jouer avec sans doc, et euh .... je me retrouve avec 2600 "trucs" que j'ai du mal a indentifier :) (  ca m'a quand meme permis de découvrir 2-3 oublis dans un projet, comme un "releaseDC")

Francky23012301 · Answer

Salut,

Au niveau d'un Opendialog cela ne me surprend. Quand tu utilises pour la seconde fois ton application avec ton opendialog tu retombes sur le meme répertoire que tu as précédemment utilisé : Donc il garde cette information en mémoire.Enfin si je me trompe pas.

A+

f0xi · Answer

en effet, j'ai tester egalement car cela a eveiller ma curiositée.

qu'on execute un opendialog statique, dynamique ou dans un thread celui prend de la memoire qui n'est libérée qu'a la fermeture de l'application.

ce qui m'a vraiment etonné c'est que meme en le creant dynamique et en le liberant ensuite, la memoire ne redescent pas.

ce qui est encore plus etrange c'est qu'il ne semble pas y'avoir de probleme dans le code (cela m'aurait etonné).

pour ce qui est du dernier repertoire ouvert, c'est le systeme qui gere cela, donc ce n'est pas stocké dans la memoire de l'appli et meme si c'etait le cas, cela ne justifierais pas les 2Mo de memoire en plus.

en fait, je pense plutot que cela vient du fait que l'appli charge a ce moment des ressources et les gardes en memoires pour accelerer l'ouverture d'autre boites de dialogue ... 
car : 
le fait d'ouvrir un opendialog ou savedialog pour la premiere fois fait augmenter de ~2Mo la memoire de maniere permanante
mais par la suite la memoire n'augmente plus quand on rouvre ces boites tours a tours.

je pense qu'il ne s'agit donc pas d'une fuite memoire mais plutot de données stockées (avec 4 thread en plus) pour les performances.

florenth · Answer

@ DeltaFX: eh non je n'ai pas de documentation  Pourtant j'ai cherché mais c'est un peu introuvable.

@ f0xi: 
"en fait, je pense plutot que cela vient du fait que l'appli charge
a ce moment des ressources et les gardes en memoires pour accelerer
l'ouverture d'autre boites de dialogue ..."
Tiens, moi qui croyais que c'étaitle système qui gérait ça. Ca me semblait plus logique car ça évite de charger les ressources des boites de dialogues dans touts les theads qui l'utilisent.

"je pense qu'il ne s'agit donc pas d'une fuite memoire mais plutot de
données stockées (avec 4 thread en plus) pour les performances." 
MemProof me signale quand même des problèmes (que je n'arrive pas à identifier) rien que sur une application vide (c-à-d juste la fiche). C'est plutot étrange ...

Si tu ne te plantes pas ......
tu ne pousseras jamais

DeltaFX · Answer

D'apres une doc d'une ancienne version, memproof detecterait meme les reservations memoire de l'IDE quand il tourne, d'ou cette "fuite"... J'ai pas testé le coup de je construit-compile l'exe, (avec les bonnes options de débugage), et je quitte delphi AVANT de lancer memproof.

En fait j'ai l'impression que memproof ne détecte aucune libération de mémoire si elle se fait pas immédiatement apres reservation.

Genre je fais un getwindowDC(GetDesktopWIndow) que je libere 10 lignes plus bas par un ReleaseDC(GetDesktopWindow, GetDC(GetDesktopWindow)); il le voit, mais un Tlist chargé d'objet au début du prog et libéré à la fin dans les regles de l'art (chaque objet dégagé de count-1 dowto 0) et MyTlist.free ensuite) il le voit pas (ou alors j'ai raté une marche).

florenth · Answer

@ DeltaFX: chez moi, il détecte les TObjectList qui sont libérés à la fin de l'application. (avec OwnsObjects := True donc les TObjectList libére lui même les objets qu'il contient).
Là où c'est plus étrange, c'est qu'il n'a pas l'air de détecter les sections "finalization". Mais il y a des fois où ça marche.

Par contre, il faut évidemment faire touner l'application en autonome (c-à-d pas depuis l'IDE) pour que MemProof fonctionne correctement.
En même temps, je suis sous D6 alors il y a peut être des différences ...

Si tu ne te plantes pas ......
tu ne pousseras jamais

DeltaFX · Answer

Ah tiens, je vais zieuter le "OwnsObjects". J'avais bien compris le fait de le faire tourner en dehors de l'IDE. Selon ce que je crois avoir lu dans la doc de la version qui connait que delphi 5 (en fait, j'ai télécharger une des version antérieure sur la page, celle avec installer et tout le toutim) et il semble que lorsque l'IDE tourne en background (meme si on lance le prog depuis memproof) mem proof voit des actions de l'IDE.

cs_flagada · Answer

Salut ! 
9 mois plus tard je reviens ici pour poser deux questions qui sont assez en rapport avec le sujet : l'optimisation de la mémoire 

1- si l'on déclare dans le uses une unité  qui n'est pas utilisée par la suite, est-ce que cela allourdi l'exe (taille et mémoire) quand même 

2- mon programme est constitué de plusieurs forms. L'une d'entre-elle (la form d'option) est assez gourmande en mémoire et pas souvent utilisée, c'est pourquoi je ne la crée pas directement au démarrage du prog mais seulement quand l'utilisateur en a besoin.
avec un truc du style :
procedure TForm1.MenuOptionsClick(Sender: TObject);
begin
    if not Assigned(Form2) then
        Form2 := TForm2.Create(Application);
    With Form2 do begin
        Show;
        SetCursorPos(Left + Width div 2, Top + Height div 2);
    end;
end;
donc, juste après le démarrage le programme prend environ 5Mo en mémoire
si l'utilisateur ouvre les options la mémoire grimpe à plus de 7Mo

ensuite quand l'utilisateur ferme la Form je voudrais libérer la mémoire et pour cela j'ai écrit ça :
procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction);
begin
    Action := caFree;
    Form2 := nil;
end;
Seulemet la mémoire occupée reste a 7Mo comment cela se fait-il 

merci d'avance

a+
fred

florenth · Answer

Re-Salut (9 mois après !)

Pour le 1), tout dépend ce que contient l'unité. s'il n'y a que du code, cela ne prend pas plus de place (la taille de l'exe reste inchangée). Par contre, si celle ci contient des ressources, sous formce de "resourcestring" ou bien des inclusions type {$R xxx.res} ou alors qu'elle fait elle même référence à d'autre unités dans ce genre, là ça prend plus de place.
Enfin, ce sont mes suppositions ...

Pour le 2), est-tu sûr de tout bien libérer dans le OnDestroy ce que tu as construit dans le OnCreate et autres ?
Sinon, si tu ré-ouvres cette fiche, la mémoire dépasse-t-elle 7 Mo ?
Sinon, saches que d'après mes tests, Delphi (ou le système) alloue une certaine quantité de mémoire lors de certaines actions (ouverture de TOpenDialog par ex.) qui n'est libérée que lorsque tu quittes l'application.

A+
Flo

cs_flagada · Answer

OK merci pour tes réponses 

çe me rassure pour les unités dans le uses, parce que à force de tester
des trucs je suis sûr qu'il y en a pas mal qui se sont rajoutées qui ne
servent plus...


pour le 2) tu as certainement raison peut-etre bien que ça vient de la mémoire allouée par delphi pour le TopenDialog ou autres trucs dans ce genre
y'a t-il un moyen simple de savoir si tout a bien été détruit ?

a+
fred

Optimisation de la mémoire occupée

11 réponses

Votre réponse

Discussions similaires