VirtualStringTree - Speicher freigeben

[dGeek]

Ich nutze in einem Testprojekt einige VST's die gut befüllt werden.
Der Speicherbedarf ist recht hoch dabei, was wohl normal zu sein scheint.

Leere ich die VST's jetzt, so bleibt der Arbeitsspeicher jedoch unverändert hoch.

Was mache ich falsch bei diesen kleinen 3 Zeilen? Oder fehlt gar etwas?

Delphi-Quellcode:

// Button-Klick zum "Freigeben" des Speichers, was nicht klappt..
VST.Clear;
VST.Free;
VST := nil;

// VST-Event:
procedure TForm1.VSTFreeNode(Sender: TBaseVirtualTree; Node: PVirtualNode);
var
  Data: PTreeData;
begin
  Data := VST.GetNodeData(Node);
  Finalize(Data^);
end;

[jaenicke]

Erstens würde ich diese Art der Datenhaltung nicht empfehlen. Ich nutze dafür lieber Klassen, das ist deutlich einfacher, da du nicht mit Pointer spielen musst. Und die kann ich dann abseits des VST in Listen oder einem Dictionary halten und auch dort ggf. freigeben. Beispiel:

Delphi-Quellcode:

VST.AddChild(nil, TMyExample.Create('blub');

// NodeDataSize muss auf SizeOf des Objekts stehen, sprich entspricht der Größe eines Pointers (NativeUInt).

Beim Auslesen habe ich im Büro dann eine Helperfunktion geschrieben, die wir nun standardmäßig für die VST nehmen:

Delphi-Quellcode:

  TExampleVirtualStringTreeHelper = class helper for TBaseVirtualTree
  private
  public
    function Get<T: class>(Node: PVirtualNode): T;
  end;

// ...

function TExampleVirtualStringTreeHelper.Get<T>(Node: PVirtualNode): T;
var
  ResultData: Pointer;
begin
  ResultData := GetNodeData(Node);
  if Assigned(ResultData) and (TObject(ResultData^) is T) then
    Result := T(ResultData^)
  else
    Result := nil;
end;

Nun kann man einfach so das Objekt wieder auslesen:

Delphi-Quellcode:

VST.Get<TMyExample>(Node)
// du bekommst so direkt das Objekt

oder, wenn man eine entsprechende Helperfunktion schreibt:

Delphi-Quellcode:

function TExampleVirtualStringTreeHelper.TryGet<T>(Node: PVirtualNode; out Value: T): Boolean;
...

if VST.TryGet<TMyExample>(Node, MyExample) then
  ShowMessage(MyExample.Value);

Zu deinem Beispiel:
Finalize solltest du nie aufrufen müssen, da die VST sich um den Speicher kümmert.
Es wird aber in der Regel so sein, dass der Speichermanager den Speicher nicht ans System freigibt, so dass du im Taskmanager nichts davon siehst. Intern wird der aber bei neuen Speicheranforderungen benutzt.

[hoika]

Hallo,
nimm doch mal FastMM4 zu Hilfe.
Fülle einige wenige Daten und gibt den Tree wieder frei.


Heiko

[Der schöne Günther]

Zitat von jaenicke:

Ich nutze dafür lieber Klassen, das ist deutlich einfacher, da du nicht mit Pointer spielen musst. [...]

Hast du eine Vermutung warum so ziemlich alle Tutorials und Artikel zum VirtualTree es dennoch mit Records und Pointern machen? Hat es überhaupt irgendwelche Vorteile?

[jaenicke]

Zitat von Der schöne Günther:

Hast du eine Vermutung warum so ziemlich alle Tutorials und Artikel zum VirtualTree es dennoch mit Records und Pointern machen? Hat es überhaupt irgendwelche Vorteile?

Weil alle vermutlich von einem einzigen ursprünglichen Beispiel abgekupfert haben und weil eine Klasse etwas langsamer sein dürfte als ein Record.
Wenn ich nur einen Integerwert ablege, ist das mit dem Record einfach nur der Integerwert an der Speicherstelle, bei einer Klasse einiges mehr.

Sobald man aber mehr Daten in dem Record hat, wird das wiederum bei der Benutzung langsamer, da jedesmal der komplette Record kopiert wird, wenn man den als Record hin- und herschiebt. Man kann natürlich auch intern immer den Pointer auf den Record verwenden.
Ich finde aber, dass man ruhig mit Klasse arbeiten kann solange mal keine Performanceprobleme hat. Und die habe ich selbst mit vielen tausend Einträgen bisher nicht mit Klassen. Denn Geschwindigkeit ist heutzutage normalerweise nicht mehr das Hauptaugenmerk.

[Zacherl]

Zitat von jaenicke:

Finalize solltest du nie aufrufen müssen, da die VST sich um den Speicher kümmert.

Das stimmt nicht. Finalize musst du bei Verwendungs von Records im VST die beispielsweise Strings erhalten auf jeden Fall verwenden.

Ich habe eine Ahnung, warum du Memory leakst. Enthält dein VST zufällig Nodes von denen einige zur Laufzeit niemals sichtbar sind? VST ruft nämlich das OnFreeNode Event nur dann auf, wenn die entsprechende Node vorher validated war. Validiert wird die Node aber erst, wenn sie mindestens einmal gezeichnet wurde.

Hatte dieses Problem vor einigen Jahren auch schonmal. Da mein Datensatz nicht wirklich groß war, habe ich einfach alle Nodes per Hand nach dem Hinzufügen mit der ValidateNode Methode validiert. Kann dir aber nicht sagen, wie sich das bei sehr großen Datenmengen auf die Performance auswirkt.

[Daniel]

Zitat von Zacherl:

Kann dir aber nicht sagen, wie sich das bei sehr großen Datenmengen auf die Performance auswirkt.

Meine Bäume haben (gerade im Frühling *g*) rund 150.000 Einträge und da wirkt sich das explizite ValidateNode() nicht messbar aus.


Größere Records konterkarieren meiner Ansicht nach die Idee des virtuellen Baumes, da man dadurch ja seine Daten doppelt. Der With ist ja, dem Baum ein möglichst schlankes Paket mit auf den Weg zu geben. Ich reiche da i.A. nur einen Pointer auf mein Datenobjekt rein.

[dGeek]

Ich weiß zwar jetzt woran es lag, dass etwa 800 Einträge 100 MB Arbeitsspeicher verschlungen haben und nicht wie vorgesehen etwa 20.

War ein ShortString nicht ein WideChar und belegt somit mehr Speicher? Haut mich, wenn ich mich irre ..

[DeddyH]

Ein ShortString ist ANSI-kodiert (1 Zeichen = 1 Byte).

[himitsu]

String[x] = maximal 256 Byte (x AnsiChars + 1 Längenbyte)

ShortString = String[255]