VirtualTreeView et gestion mémoire

Version imprimable

17/08/2021, 19h09
free07

VirtualTreeView et gestion mémoire

Bonjour

J'ai un programme qui utilise VirtualTreeView pour l'affichage d'une liste d'objet ( avec TObjectList), les objets sont ajoutés au VirtualTreeView par AddChild et c'est lui qui en est propriétaire.

OwnsObjects de TObjectList est à False car c'est le VirtualTreeView qui libère la mémoire de la liste des objets lorsqu'il est détruit.

Mais dans certains cas, j'aimerai pouvoir maitriser complètement la libération des objets de la liste : est il possible d'indiquer au VirtualTreeView de ne pas s'occuper de la libération mémoire ? dans ce cas, je pourrai mettre OwnsObjects à True et ce sera le TObjectList qui libérera la mémoire.

J'ai cherché sur le net mais je n'ai pas trouvé l'info. :(
17/08/2021, 20h03
ShaiLeTroll

Il me semblait que le TVirtualTreeView gérait des pointeurs comme UserData et pas des objets
Faut dire que je ne l'ai jamais utilisé, j'ai regardé par curiosité en C++Builder, il y a dix ans.

D'ailleurs, à l'époque tout était TVirtualNode \ PVirtuaNode soit des record, la donnée utilisateur était dedans

Citation:

Envoyé par ShaiLeTroll

Il me semblait que le TVirtualTreeView gérait des pointeurs comme UserData et pas des objets

Oui c'est vrai, je transmets au TVirtualTreeView la liste des pointeurs du TObjectList et je suppose que lorsque le TVirtualTreeView est détruit il supprime tous les pointeurs contenus dans les noeuds et je me dis que cela doit impacter les pointeurs du TObjectList, je me trompe ?

A la réflexion oui je me trompe, pour remplir les pointeurs sur les données du TVirtualTreeView on utilise une class et c'est les données de cette classe qui sont supprimées
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 // Node data record for the the document properties treeview. PPropertyData = ^TPropertyData; TPropertyData = class Name : String; ValueType: TValueType; Value: WideString; Id : Integer; Changed: Boolean; ImageId : Integer; objet : TObject; // Objet de la liste TObjectList end; MonObjet : TObject; MaListeObjet : TObjectList; PropertyData : TPropertyData; Node : PVirtualNode; ... VirtualTreeView.NodeDataSize := SizeOf(TPropertyData); for i:= 0 to MaListeObjet.count -1 do begin MonObjet := TObject(MaListeObjet.Items[i]); PropertyData := TPropertyData.Create; PropertyData Name := MonObjet.Nom; PropertyData.ValueType := 0; PropertyData.objet := MonObjet; PropertyData.ImageId :=0 ; Node := TVirtualTreeView.AddChild(nil, PropertyData); // On ajoute chaque noeud end;
Donc la liste des objets du TObjectList n'est pas impactée, là je me trompe pas n'est ce pas ?

La liste n'est pas impactée à la vision du code actuel
Cependant comme sont libérés les TPropertyData ? j'ai un doute que la libération soit automatique, un évènement OnDeletion comme sur le TTreeView ?

Le VirtualTreeView alloue et libère les PVirtuaNode incluant la mémoire utilisateur de la taille définie par NodeDataSize
Mais il ne sait pas libéré un pointeur typé

Quand tu défini TPropertyData en class, pour lui, c'est 4o en plus, et il va juste libérer les 4o mais en aucun cas appeler un Destroy ou un Dispose si cela avait été un pointeur de record, il n'a qu'un pointeur lambda non typé, il n'a pas la possibilité d'utiliser les RTTI pour finaliser les types record ou string pointés.

bizarre :
Code:

1 2 MonObjet := TObject(MaListeObjet.Items[i]); PropertyData Name := MonObjet.Nom;
Tu n'as pas osé redéfinir TObject ?
MaListeObjet est TObjectList et donc Items[] est TObject, cast curieux

Un ReportOnMemoryLeak doit indiquer qu'un aucun TPropertyData n'est libéré car seule la consommation mémoire du pointeur en lui l'est !

En D7, je n'aurais pas eu de scrupule à faire
Code:

1 2 3 4 5 6 7 8 9 TPropertyData = packed record // un record non une class Name : String[255]; // pas de pointeur que des types simples ValueType: TValueType; Value: String[255]; // Cast en WideString ultérieur Id : Integer; Changed: Boolean; ImageId : Integer; objet : TObject; // Objet de la liste TObjectList, weak référence end;
Grace à NodeDataSize l'allocation des PVirtuaNode aurait contenu directement toutes les données sans pointeurs (String étant un pointeur)
J'évalue SizeOf(TPropertyData) à 256 + 4 + 256 + 4 + 1 + 4 + 4 = 529 (ça dépend la taille de l'enum TValueType et des options de compilation sur la taille minimale des enum)

En D10, avec l'unicode, le String[255] est un risque de perte de donnée (si l'on travaille dans une application Française et Chinoise en simultané par exemple)
TPropertyData on le laisse en class
Par flemme, une TObjectList<TPropertyData> en OwnsObject comme GarbageCollector

Citation:

Envoyé par ShaiLeTroll

La liste n'est pas impactée à la vision du code actuel
Cependant comme sont libérés les TPropertyData ? j'ai un doute que la libération soit automatique, un évènement OnDeletion comme sur le TTreeView ?

C'est avec un Clear du VirtualStringTree, de ce que j'ai pu voir dans le code source, ils font un FreeMem de chaque noeud
Citation:
Envoyé par ShaiLeTroll
bizarre :
Code:

1 2 MonObjet := TObject(MaListeObjet.Items[i]); PropertyData Name := MonObjet.Nom;
Tu n'as pas osé redéfinir TObject ?
MaListeObjet est TObjectList et donc Items[] est TObject, cast curieux
Oui en fait j'ai oublié de préciser que c'est TMonObjet qui cast :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 // Node data record for the the document properties treeview. PPropertyData = ^TPropertyData; TPropertyData = class Name : String; ValueType: TValueType; Value: WideString; Id : Integer; Changed: Boolean; ImageId : Integer; objet : TObject; // Objet de la liste TObjectList end; TMonObjet : class (TObject) ... end; MonObjet : TMonObjet; MaListeObjet : TObjectList; PropertyData : TPropertyData; Node : PVirtualNode; ... VirtualTreeView.NodeDataSize := SizeOf(TPropertyData); for i:= 0 to MaListeObjet.count -1 do begin MonObjet := TMonObject(MaListeObjet.Items[i]); PropertyData := TPropertyData.Create; PropertyData Name := MonObjet.Nom; PropertyData.ValueType := 0; PropertyData.objet := MonObjet; PropertyData.ImageId :=0 ; Node := TVirtualTreeView.AddChild(nil, PropertyData); // On ajoute chaque noeud end;
Citation:

Envoyé par ShaiLeTroll

Un ReportOnMemoryLeak doit indiquer qu'un aucun TPropertyData n'est libéré car seule la consommation mémoire du pointeur en lui l'est !

Il faut que je regarde comment utiliser les ReportOnMemoryLeak, j'ai installé la version gratuite de fastMM4
Citation:
Envoyé par ShaiLeTroll
En D7, je n'aurais pas eu de scrupule à faire
Code:

1 2 3 4 5 6 7 8 9 TPropertyData = packed record // un record non une class Name : String[255]; // pas de pointeur que des types simples ValueType: TValueType; Value: String[255]; // Cast en WideString ultérieur Id : Integer; Changed: Boolean; ImageId : Integer; objet : TObject; // Objet de la liste TObjectList, weak référence end;
Grace à NodeDataSize l'allocation des PVirtuaNode aurait contenu directement toutes les données sans pointeurs (String étant un pointeur)
J'évalue SizeOf(TPropertyData) à 256 + 4 + 256 + 4 + 1 + 4 + 4 = 529 (ça dépend la taille de l'enum TValueType et des options de compilation sur la taille minimale des enum)

En D10, avec l'unicode, le String[255] est un risque de perte de donnée (si l'on travaille dans une application Française et Chinoise en simultané par exemple)
TPropertyData on le laisse en class
Par flemme, une TObjectList<TPropertyData> en OwnsObject comme GarbageCollector
Sur ce projet, j'utilise Delphi 10.2, merci pour toutes tes précisions !

Si D10, c'est inclu ReportMemoryLeaksOnShutdown
RTLMM de D10 est une version simplifie de FastMM4 (euh 4.72 je crois)

Dans le DPR, je mets ceci, le message de log n'est affiché qu'un Debug sous Delphi
Code:

1 2 3 4 5 6 7 {$IFDEF DEBUG} {$WARN SYMBOL_PLATFORM OFF} System.ReportMemoryLeaksOnShutdown := DebugHook <> 0; {$WARN SYMBOL_PLATFORM ON} {$ELSE DEBUG} System.ReportMemoryLeaksOnShutdown := False; {$ENDIF DEBUG}
Mais si tu as trop de fuite mémoire, si le log dépasse 32Ko, cela échoue à l'affichage donc là faut FastMM4 pour la version fichier du log.

Sinon, comme je disais le FreeMem libère le PVirtuaNode (soit SizeOf(TVirtuaNode) + NodeDataSize) mais ne libère pas le TPropertyData

Tu peux aussi écrire

Code:

MaListeObjet : TObjectList<TMonObject>;

Cela évite le cast par la suite

Bonjour,

Voici mon utilisation mais en passant par des pointeurs plutôt que des objets :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
Type
  // Node pour VirtualTreeView
  pNodeLibData = ^tNodeLibData;
 
  tNodeLibData = record
    cnlLibrairie: String;
    cnlComment: String;
    cnlLinkFile: pLinkFile;
    cnlImage: Byte;
  end;
 
var
  pProgFileTempTmp: pProgFileTemp;
  pNodeLibDataTmp : pNodeLibData;
  XNodeRobot      : PVirtualNode;
 
  // **********************************
 
  procedure AddNodeDir(NodeFather: PVirtualNode; pLFRef: pLinkFile; pPFFather: pProgFile);
  var
    pLinkFileTmp: pLinkFile;
    XNodeNew    : PVirtualNode;
  begin
    XNodeNew := vtvLibrairie.AddChild(NodeFather); // Creation du noeud
    pNodeLibDataTmp := vtvLibrairie.GetNodeData(XNodeNew); // Creation du pointeur
    with pNodeLibDataTmp^ do
    begin
      cnlLibrairie := 'xxx';
      cnlLinkFile := pLFRef; // Pointeur vers donnée associée
      cnlImage := cImgAppliLibrairie; // Numero d'Icone
      cnlComment := 'Blabla';
    end;

Le VirtualTree libère bien tout ce qui est visuel (VirtualNode et pNodeLibData, mais je conserve mes données (stockées dans une tList) qui sont donc libérées manuellement.
Pas de soucis de fuite mémoire (System.ReportMemoryLeaksOnShutdown := true;)

Cordialement,

Je suppose que c'est pLFRef qui dans une TList

Cependant, pas de fuite mémoire m'étonne sur tNodeLibData contenant des string

Comme AddChild alloue un pointeur PVirtualNode de taille TVirtualNode + NodeDataSize
Tu l'utilises via pNodeLibData, tu peux manipuler la zone mémoire sans soucis mais lorsque le VTV libère le TVirtualNode + NodeDataSize que devienne les pointeurs cnlLibrairie et cnlComment ?
Comme il n'y a pas de typage de la zone mémoire PVirtualNode.Data, il n'y a pas de finalisation donc pas de diminution du compteur de référence ou de libération pour une chaine locale.

C'est bien pour cela que TTreeView a un évènement OnDeletion pour libérer le Pointer Data complètement via Dispose utilisant un typage en Pointeur sur Record et faire la finalisation ou alors comme TObject c'est le Destructeur qui libère la chaine d'objet et il y aussi une finalisation des types référence.

Faudrait tester de lancer plusieurs fois la fonction de remplissage du VTV \ Clear pour voir si la mémoire augmente avec FastMM4.GetMemoryManagerState ou System.GetMemoryManagerState ou encore GlobalMemoryStatus\Ex
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 //------------------------------------------------------------------------------ class function TTestPerformanceExtensionPlugInImplementationEvaluationDelphiMM.TUtilities.GetMemoryDetail(): TMemoryDetail; var mms: TMemoryManagerState; isbts: Integer; begin System.GetMemoryManagerState(mms); Result.Medium := mms.TotalAllocatedMediumBlockSize; Result.Large := mms.TotalAllocatedLargeBlockSize; Result.Small := 0; for isbts := Low(mms.SmallBlockTypeStates) to High(mms.SmallBlockTypeStates) do with mms.SmallBlockTypeStates[isbts] do Result.Small := Result.Small + InternalBlockSize * AllocatedBlockCount; Result.Total := Result.Medium + Result.Large + Result.Small; end;

La documentation utilise vicieusement du String[255] et ShortString, le malin !

Mais à la fin on a la réponse

Citation:

While we are at deleting nodes:

Every data of the record is automatically free as soon as this is required. In this case it is not enough, however, to free the memory, which holds the pointer to the class (object instance), but it is also necessary to free the memory, which is allocated by the class itself. This happens by calling the destructor of the class in the OnFreeNode event:

procedure TMyForm.MyTreeFreeNode(Sender: TBaseVirtualTree; Node: PVirtualNode);

begin
// Free here the node data (Note: type PtreeData = ^rTreeData).
PTreeData(Sender.GetNodeData(Node)).BasicND.Free;
end;

Et voilà on a la démonstration pour libérer un objet via le Node.Data sans avoir de liste annexe.

Donc pour Galet, je recommande
Code:

1 2 3 4 5 6 7 8 procedure TFormX.TreeFreeNodeEventHandler(Sender: TBaseVirtualTree; Node: PVirtualNode); begin with pNodeLibData(Sender.GetNodeData(Node)) do begin cnlLibrairie := ''; cnlComment := ''; end; end;
Cependant j'ignore si l'on pourrait oser plus court
Code:

1 2 3 4 procedure TFormX.TreeFreeNodeEventHandler(Sender: TBaseVirtualTree; Node: PVirtualNode); begin Finalize(pNodeLibData(Sender.GetNodeData(Node))^); // ou Finalize(pNodeLibData(Sender.GetNodeData(Node))); avec un "procedure Finalize(var V; [ Count: NativeUInt]); overload;" c'est toujours un peu difficile de savoir ce que cela attend end;
Et pour free07
Code:

1 2 3 4 5 procedure TFormX.TreeFreeNodeEventHandler(Sender: TBaseVirtualTree; Node: PVirtualNode); begin // TPropertyData(Sender.GetNodeData(Node)).objet.Free(); // Si l'on oublie toute TObjectList TPropertyData(Sender.GetNodeData(Node)).Free(); end;

Bonjour et merci ShaiLeTroll pour tes retours.

Effectivement, mon commentaire était incomplet, la libération des chaines est faite, à la libération du nœud, par
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 procedure TfrmMain.vtvLibrairieFreeNode(Sender: TBaseVirtualTree; Node: PVirtualNode); var pNodeLibDataTmp: pNodeLibData; begin pNodeLibDataTmp := vtvLibrairie.GetNodeData(Node); if Assigned(pNodeLibDataTmp) then begin with pNodeLibDataTmp^ do begin cnlLibrairie := ''; cnlComment := ''; cnlLinkFile := nil; end; Finalize(pNodeLibDataTmp^); end; end;
Je contrôle actuellement la non fuite de mémoire avec un "System.ReportMemoryLeaksOnShutdown := true;" à la fermeture de l'application et te confirme qu'après plusieurs chargements et libérations (sans quitter l'application), toujours pas de fuite.
Cette méthode est appliquée dans 6 virtualTreeView et cela semble résister....

Je ne souhaite pas 'polluer' la discussion de Free07...Dans tous les cas, merci pour tes remarques...
Belle journée,

19/08/2021, 15h04
ShaiLeTroll

Effectivement, avec le gestionnaire de l'évènement OnFreeNode ainsi codé, sans connaître le composant, tout cela me semblait logique pour que garantir une bonne utilisation de la mémoire.
Ma remarque sur les fuites étaient basé sur le fait que je n'avais pas à ce moment connaissance de OnFreeNode dont je supposais l'existence par analogie au OnDeletion du TTreeView, merci d'avoir ajouter votre dernier code, il confirme exactement ce que je pensais, cela montre que rien est "magique", il y a toujours une bonne raison pour que la libération soit faite.
19/08/2021, 15h46
free07

Bonjour,

Idem pour moi, j'ai fait un Free des données du noeud ( TpropertyData ) dans l'évènement OnFreeNode. ça fonctionne !

Merci à vous deux !

Je met en résolu