Hi,

kann man in einem Thread den tatsächlichen, aktuelle Speicherbedarf dieses Threads ermitteln (mit allen darin erzeugten Objects). Wenn ja, wie geht das?

Nein.



Vielleicht mit FastMM im FullDebugMode, wenn er zu den Speicheranforderungen die ThreadID und CodeAdresse speichert.
Aber das drifft natürlich nur Speicheranforderungen über den Delphi-Speichermanager, aber nicht den vom OLE oder direkt VirtualAlloc und Co.

Ein ShortString liegt direkt auf dem Heap, bzw. "in" einem Objekt/Record drin,
die anderen LongStrings (AnsiString, UnicodeString/String, UTF8String usw.) liegen im DelphiMM,
aber ein WideString wird über die OleAuth-API verwaltet und nutzt demnach deren Speichermanager.

Variant (Strings/Arrays/Pointer) liegt ebenfalls oft außerhalb.

...



Man könnte sich selber in GetMem/FreeMem reinhängen und dort z.B. mitzählen.

Zitat von Hobbycoder:

Hi,

kann man in einem Thread den tatsächlichen, aktuelle Speicherbedarf dieses Threads ermitteln (mit allen darin erzeugten Objects). Wenn ja, wie geht das?

Ja, installiere "Process Hacker", der listet jeden Thread einzeln sehr detailliert auf.
Das "wie" kann man dem Quelltext vom Process Hacker entnehmen.

Zitat von KodeZwerg:

Ja, installiere "Process Hacker", der listet jeden Thread einzeln sehr detailliert auf.

Details liefert er, aber der Speicherverbrauch jedes Threads ist nicht dabei.

Grüße
Dalai

Wie auch - jeder Thread kann den Speicher verwenden. Einfaches Beispiel sind Nur-Lese-Zugriffe, aber auch Lese-Schreib-Zugriffe können aus unterschiedlichen Threads kommen - man sollte das halt nur thread-sicher gestalten (was auch immer das im Kontext bedeutet). Wäre das nicht möglich, würde das den Einsatz von Threads drastisch einschränken.

Delphi kennt zwar threadvar, aber darum geht es hier wohl nicht.

Vielleicht sollte man einen Schritt zurück gehen und den eigentlichen Grund der Frage betrachten?

Zitat von Dalai:

Zitat von KodeZwerg:

Ja, installiere "Process Hacker", der listet jeden Thread einzeln sehr detailliert auf.

Details liefert er, aber der Speicherverbrauch jedes Threads ist nicht dabei.

Grüße
Dalai

Ahh mist, ich habe es mit Prozesse verwechselt, mein Fehler!

Vielen Dank für die Anworten.
Das Problem konnte ich dann doch so lösen. Es ging darum, dass der Speicherbedarf einer Anwendung langsam aber kontinuierlich gestiegen ist. In dem Projekt gibt es viele Threads für die Datenverabreitung, und ich hätte das gerne über den Speicherbedarf der Threads ermittelt. Weil ich aber keine Lösung gefunden habe, habe ich dann Thread für Thread deaktiviert bzw. teilweise umgeschrieben. Das hat alles einen Tag in Anspruch genommen, aber letztlich zum Ziel geführt. Am Ende war es natürlich nur ein fehlendes Free im Destructor einer komplexen Datenstruktur.

Zitat von Hobbycoder:

Am Ende war es natürlich nur ein fehlendes Free im Destructor einer komplexen Datenstruktur.

Nur um sicherzugehen, ReportMemoryLeaksOnShutdown war aktiv? Damit lassen sich solche Probleme eigentlich schnell erkennen. Das hilft natürlich nicht, wenn am Programmende ordentlich aufgeräumt wird, während der Laufzeit aber nicht.

Zitat von Hobbycoder:

VEs ging darum, dass der Speicherbedarf einer Anwendung langsam aber kontinuierlich gestiegen ist. (...) Am Ende war es natürlich nur ein fehlendes Free im Destructor einer komplexen Datenstruktur.

Ja, wenn beim Beenden des Programms aufgeräumt wird, sind Memory Leaks nicht mehr so leicht zu entdecken.
Mit dem schon genannten FastMM(4) ist es möglich (anstatt der Memory Leak Auflistung am Programmende) eine Liste der belegten Blöcke zu erstellen, und periodisch in einer Datei zu speichern. (Zum Beispiel alle 30 Sekunden). Wenn man diese dann mit einem Editor öffnet und regelmäßig aktualisiert, kann man erkennen, ob ein Memory Leak im vom Memory Manager verwalteten Speicher besteht.

Dazu habe ich vor Jahren eine kleine Demo-Anwendung erstellt. Hier ist ein Link zu einem Artikel, mit einem Screenshot:
https://mikejustin.wordpress.com/201...almm-new-demo/
(die Links im Artikel sind nicht mehr funktional)
(Es war einmal eine Demo für das jetzige Daraja HTTP Framework)

Die Grafik ist keine Zeitlinie, sondern zeigt an, wie viele Instanzen für welche Blockgrößen jeweils existieren. Wenn zu einer der Blockgrößen immer höhere Werte erreicht werden, ist das ein Indiz für ein Leak.