Hauptspeicherverbrauch einer Anwendung, D Seattle liefert merkwürdige Werte

    Hauptspeicherverbrauch einer Anwendung, D Seattle liefert merkwürdige Werte

    Hallo,

    ich habe eine Funktion, welche mir den Speicherbedarf einer Anwendung anzeigt, nach Delphi Seattle übertragen, und siehe, es war gut.
    Dachte ich...
    Folgende Diskrepanz: Mein Testprogramm zeigt im Taskmanager ca 4 MB an, die selbstgeklaute Funktion über 11 MB.
    Die Funktion arbeitet mit sog. "Process_memory_counters" , einer Recordstruktur, die diverse Speicherlastzahlen enthält.
    Die eigentliche Zeile lautet:

    Delphi-Code

    1. worss:= pmc.WorkingSetSize;

    Bis dahin stimmt alles, es wird auch der richtige pmc genommen.
    Preisfragen:
    - woher stammt die obige Diskrepanz ?
    - wie komme ich ggf. an die Zahl im Taskmanager ?
    Gruß ism
    Morgen ist Heute schon Gestern
    Hallo,

    hier der Quelltext der geklauten Funktion:

    Delphi-Code

    1. function getWorkMemSize(modulname:string):Cardinal;
    2. type TProcArray = array[0..2047] of Cardinal;
    3. pTProcArray = ^TProcArray;
    4. Var ANZ, cb:Cardinal;
    5. A:TProcArray;
    6. i, Pr,bis:integer;
    7. PRH:HWND;
    8. Modul:DWORD;
    9. PrName:array[0..255] of char;
    10. pmc: Process_memory_counters;
    11. zeile:string;
    12. s_space:string;
    13. worss:cardinal;
    14. su:string;
    15. erg:integer;
    16. begin // <getWorkMemSize>
    17. if not EnumProcesses(@A,sizeof(A),ANZ) then
    18. begin
    19. Result:=0;
    20. exit;
    21. end;
    22. erg:=0;
    23. Pr:= ANZ div sizeof(DWORD);
    24. for i:= 0 to PR-1 do
    25. begin // <for>
    26. PRH:=OpenProcess(PROCESS_QUERY_INFORMATION or
    27. PROCESS_VM_READ,
    28. false,A[i] );
    29. if PRH <> 0 then
    30. begin
    31. EnumProcessModules(PRH, @Modul, sizeof(Modul),ANZ);
    32. GetModuleFileNameEx(PRH, Modul, PrName, sizeof(PrName));
    33. GetProcessMemoryInfo(PRH,@pmc, sizeof(pmc));
    34. worss:= pmc.WorkingSetSize;
    35. if PrName = modulname then
    36. begin
    37. erg:=worss;
    38. break;
    39. end;
    40. CloseHandle(PRH);
    41. end;
    42. end; // </for>
    43. Result:=erg;
    44. end; // </getWorkMemSize>


    Bis zu der Stelle, wo der pmc angesprochen wird scheint alles ok , wenn auch sher kryptisch , zu sein.
    Die pmc's werden im ganzen Internet als die Stelle, wo man den Speicherverbrauch abgreifen kann, genannt.
    Nur steht eben in den Variablen unter W7 ein viel zu hoher Wert...
    Preisfrage: Wie macht der Taskmanager das ?
    Ach so: Der Speicherbedarf hat auch bei Release-Compilaten außerhalb der IDE diese Diskrepanz.

    ism
    Morgen ist Heute schon Gestern

    ismirschlecht schrieb:

    Ein D7-Programm lieferte unter Windoof 7 auch abenteuerliche Werte bezüglich des Hauptspeicherverbrauchs.
    Unter XP stimmten die Zahlen aus dem Programm und die im Taskmanager überein.


    Was daran liegen könnte, das M$ sowohl unter Windows 7, wie jetzt auch unter Windows 10, die Speicherverwaltung "überarbeitet" bzw. verändert hat. So haben einige Progremme "plötzlich" mehr Speicherverbrauch, als noch unter Windwos XP angezeigt.

    winfuture.de/news,88541.html

    DL
    Es gibt Wissenschaftler, die behaupten, dass Logik "universell", also überall gleich, sei...
    Ich treffe täglich Menschen, die mit "ihrer" Logik das Gegenteil beweisen.
    So, ausprobiert.
    Der "höhere" Speicherverbrauch ist ab Windows 7 zu bemerken.

    Der Link sagt aber nur etwas von einem Kompressionsverfahren ab Win10 ?!
    Außerdem geht es in dem Artikel um den GESAMTEN RAM-Verbrauch, aber ich wüsste nicht wieso dies den RAM-Verbrauch eines einzelnen Prozesses betreffen sollte?

    Ideen:
    1. Kann es sein, dass EnumProcessModules mit 32-bit und 64-bit durcheinander kommt und man lieber mit EnumProcessModulesEx arbeiten sollte?
    2. workingSetSize zählt den Shared-Bereich mit (siehe hier: msdn.microsoft.com/en-us/libra…op/ms684891(v=vs.85).aspx). Vielleicht hat sich das ab Win7 geändert? Und vielleicht zählt die Task-Manager-Routine diesen Shared-Bereich NICHT mit? Es würde ja auch Sinn ergeben, denn im Task-Manager erwartet man, dass die Summen der RAM-Nutzungs-Zahlen aller Prozesse den Gesamtspeicher ergeben :) .
    Ich habe auch nicht die Löung deine Problemes aufzeigen wollen, sondern nur einen Grund für die "nicht simmenden Angaben".
    Es scheint ja nun offensichtlich so zu sein, dass es unter Win XP tut, unter Win 7 und größer nicht.
    Ein Grund dafür "könnte2 das geänderte Speichermanagemant sein, zu dem der vorhandenen Code eben nicht mehr passt.

    DL
    Es gibt Wissenschaftler, die behaupten, dass Logik "universell", also überall gleich, sei...
    Ich treffe täglich Menschen, die mit "ihrer" Logik das Gegenteil beweisen.