Windows-API: Speicherverbrauch der laufenden Anwendung abfragen

[Der Martin]

Hallo Rolf,

hilft Dir das Process Status API weiter?

https://docs.microsoft.com/en-us/windows/win32/psapi/about-psapi

nicht wirklich; einen Teil der dort verlinkten Funktionen hatte ich gestern schon gefunden. Es scheitert immer daran, dass ich zuerst "meine eigene" Prozess-ID herausfinden muss, über deren Herkunft die API-Dokumentation den Mantel des Schweigens deckt.
Wenn ich die erstmal habe - okay, dann käme ich da weiter.

Entweder "Memory Usage" für den Gesamtverbrauch oder "Working Set" für das, was aktuell im RAM (und nicht im Pagefile) ist.

Danke. Über die Ausdrücke habe ich mich nämlich auch schon gewundert und nicht gefunden, was sie bedeuten.

Dabei mache ich ausgiebig Gebrauch von dynamischer Speicherreservierung mit GlobalAlloc() und GlobalFree().

Aber bitte nur im Notfall. Diese Funktionen sind da, um Kompatibilität für 16-bit Anwendungen bereitzustellen.

Jein. Microsoft schreibt zwar etwas in der Richtung. Aber solange es gleichzeitig heißt, dass diese Funktion Wrapper für die Heap-Funktionen sind, benutze ich lieber GlobalAlloc() und Co. und freue mich, dass ich einen Parameter weniger übergeben muss (das Heap-Handle).

Neue Anwendungen sollen die Heap-Funktionen verwenden. Die sind auf der genannten Seite verlinkt.

Ja. Aber in der Beschreibung von HeapAlloc() habe ich auch empfindliche Einschränkungen gefunden. Zum Beispiel, dass ich mit HeapAlloc() maximal 0x7FFF8 Bytes am Stück anfordern kann. Das sind knapp 512kB. Mit GlobalAlloc() kann ich dagegen auch mal 12MB am Stück kriegen.

Und ich habe schon andere Abhandlungen gelesen, die letztendlich das Fazit ziehen, dass es bei heutigen Windows-Versionen eigentlich egal ist, welchen Satz an Funktionen man für die Speicherverwaltung verwendet (solange man sie nicht mischt), denn seit der 32bit-Ära würde Windows sowieso nicht mehr zwischen dem lokalen und dem globalen Heap unterscheiden.

Die Existenz eines private heap bedeutet übrigens auch, dass die Speichermenge, die für deinen Prozess gemeldet wird, unerwartet groß ist. Oder sich nicht verändert, wenn Du einen HeapAlloc machst. Eventuell musst Du mit GetProcessHeap, QueryHeapInformation oder HeapWalk ein paar Details austüfteln.

Das wird mir zu kompliziert.

Inwieweit malloc und Konsorten unter der Haube auf die Heap-Funktionen zugreifen oder ob sie einen von der C Runtime allocierten Heap unterverwalten, weiß ich nicht. Das hängt von der jeweiligen CRT und mutmaßlich auch vom gewählten Speichermodell ab.

Speichermodelle gab es früher mal, bei 32bit-Anwendungen mit linearer Adressierung eigentlich nicht mehr. Und ja, die Überlegung ist schon okay, aber für Windows-Anwendungen sind malloc() und free() auch nur Wrapper für die passenden Betriebssystemfunktionen.

Aber eigentlich sollte man Speicherverwaltung über die C Runtime machen und nicht direkt beim Betriebssystem.

Das sehe ich komplett anders. Wenn mir das Betriebssystem direkt eine API-Funktion für eine bestimmte Aufgabe bietet, dann nutze ich die auch direkt, anstatt vergleichbare CRTL-Funktionen, die dann irgendwann auch nur die API-Funktion aufrufen. Deswegen benutze ich auch CreateFile() und Co. anstatt fopen(). Das Ziel ist, dass ein großer Teil der CRTL beim Linken als überflüssig (nicht benutzt) erkannt wird und rausfällt - im Idealfall die komplette Runtime. Das ergibt kleinen, kompakten Code.

Anders seht's aus, wenn mir die CRTL eine Funktion bietet, mit der das System-API nicht in der Form dienen kann, und die ich auch nicht mal schnell in 10min von Hand nachbauen kann.

Live long and pros healthy,
 Martin