destructor TMyObject .Destroy
begin
// je supprime bien sur ts ce que j'ai pu creer ici, mais pr l'exemple, ca n'en vaut pas la peine ...
inherited Destroy;
end;
{ - TMyList ---------------------------------------------------------- }
constructor TMyList .Create;
begin
inherited Create(True);// OwnObject est a True, Donc libération des Objects Automatique !
end;
function TMyList .Get( Index : Integer ) : TMyObject;
begin
Result := inherited Get( Index );
end;
procedure TMyList .Put( Index : Integer; Item : TMyObject);
begin
inherited Put( Index, Item );
end;
procedure TAutreObject .RemoveAll;
var
i : integer;
begin
for i:=0 to MyList.Count-1 do begin
//Supprime un objet spécifié de la liste
// et (si OwnsObjects est à true) libère l'objet.
MyList.Rmove(MyList.Items[i]);
end;
MyList.Capacity := MyList.Count;
// Mais il ne supprime rien ! Enfin si , mon vecteur est vide
//mais ma mémoire est toujours autant occupée , prq ?!!
end;
Voila ben ma question est simple , Pourquoi ca ne me libère rien coté mémoire ?!
Caribensila
Messages postés2527Date d'inscriptionjeudi 15 janvier 2004StatutMembreDernière intervention16 octobre 201918 29 janv. 2009 à 16:09
... Si je t'ai bien suivi, quand une application risque trop de fragmenter la ram, on a intérêt à s'orienter vers les tableaux plutôt que les listes...
Et peut-être même aussi vers TFileStream s'il y a vraiment énormément d'objets?
cs_rt15
Messages postés3874Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention 7 novembre 201413 29 janv. 2009 à 16:35
Ouaich.
Cela dit les tas sont plutôt bien codés en général, donc ça se passe plutôt bien.
Genre ton appli alloue pour 1 Go d'objets -> Consommation mémoire 1 Go.
Ton appli libère pour 500 Mo d'objets -> Fragmentation -> Consommation à 750 Mo.
Ton appli alloue pour 500 Mo d'objets -> Remplissage des trous -> Consommation mémoire 1 Go.
Bref, c'est pas si affolant que ça la mémoire qui redescend pas. C'est dommage, mais ça n'aura pas tant d'influence que ça sur les pics, qui sont surtout ce que ressent l'utilisateur.
[troll]
De toute façon avec le Delphi, même sans trop faire gaffe, on fait toujours mieux que ce que l'on ferait avec un autre langage moderne.
/troll
Nicolas___
Messages postés992Date d'inscriptionjeudi 2 novembre 2000StatutMembreDernière intervention24 avril 20131 29 janv. 2009 à 16:40
"- Imaginons une application qui doit créer de très
nombreux objets et les libérer presque aussitôt. Si on n'a pas bcp de
chance, ne risque t-on pas d'arriver à un plantage du système, même si
le code est irréprochable du côté des libérations "
C'est bien ce qui m'arrive avec mon appli, et ça me fait *** !
Je travaille avec des bitmaps, donc tu imagines facilement a quelle vitesse la ram peut être saturé !
Caribensila
Messages postés2527Date d'inscriptionjeudi 15 janvier 2004StatutMembreDernière intervention16 octobre 201918 29 janv. 2009 à 17:43
@Nico
Peut-être pourrais-tu t'inspirer de la technique de GRANDVIZIR?
Je le cite :
« ... en effet, ~.Free avec les BMP est très ennuyeux car Create et Free répétés finissent par submerger le swap et à faire ramer l'application terriblement. J'ai tjs rusé: je partage les ressources au lieu de les créer et les détruire. Ainsi, dans un composant, si j'ai besoin d'un bitmap, je crée un TBitmap une fois pour toute et qui subit toutes les tortures inimaginables et rend l'âme après clic sur la croix. »
cs_Delphiprog
Messages postés4297Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 9 janvier 201332 3 févr. 2009 à 00:23
J'arrive après la bataille. Néanmoins, les explications données par rt15 justifient la trentaine de posts pour une question qui aurait dû être résolue en 3 réponses maximum.
@nicolas___ : tu dis "moi aussi , d'ailleurs je ferais des fautes plus souvent". Vas-y mollo tout de même et, comme le reste, consomme avec modération (comme disent les modérateurs ).
May Delphi be with you !
<hr color="#008000" />Pensez à cliquer sur Réponse acceptée lorsque la réponse vous convient.