Unerklärlicher Speicherfresser

[TurboMagic]

Zitat von peterbelow:

Das sieht so aus, als wenn der Memory manager für jedes New einen 4K Speicherblock vom OS anfordert anstelle den vorherigen zu partitionieren. Sieh Dir mal das Ergebnis von GetMemoryManagerState vor und nach der Testschleife an. Falls Du nicht den default memory manager verwendest check mal alles, was zur Konfiguration des MMs gehört. Soweit ich mich erinnere gibt es da eine Möglichkeit, dem MM zu sagen, was er als "large block" ansehen soll. Wenn das aus irgendwelchen Gründen auf 0 stehen sollte würde es die Symptome erklären...

Hier was wir direkt nach der Schleife in eine Log-Datei schreiben konnten:

Small BlockTypeStates:
Internal BlockSize: 16; Useable BlockSize:12; A llocated BlockCount:3; Reserved AddressSpace:29488
Internal BlockSize: 24; Useable BlockSize:20; Allocated BlockCount:21; Reserved AddressSpace:29488
Internal BlockSize: 32; Useable BlockSize:28; Allocated BlockCount:13; Reserved AddressSpace:29488
Internal BlockSize: 40; Useable BlockSize:36; Allocated BlockCount:11; Reserved AddressSpace:29488
Internal BlockSize: 48; Useable BlockSize:44; Allocated BlockCount:4; Reserved AddressSpace:29488
Internal BlockSize: 56; Useable BlockSize:52; Allocated BlockCount:6; Reserved AddressSpace:29488
Internal BlockSize: 64; Useable BlockSize:60; Allocated BlockCount:5; Reserved AddressSpace:29488
Internal BlockSize: 72; Useable BlockSize:68; Allocated BlockCount:8; Reserved AddressSpace:29488
Internal BlockSize: 80; Useable BlockSize:76; Allocated BlockCount:5; Reserved AddressSpace:29488
Internal BlockSize: 88; Useable BlockSize:84; Allocated BlockCount:2; Reserved AddressSpace:58976
Internal BlockSize: 96; Useable BlockSize:92; Allocated BlockCount:2; Reserved AddressSpace:29488
Internal BlockSize: 104; Useable BlockSize:100; Allocated BlockCount:3; Reserved AddressSpace:29488
Internal BlockSize: 112; Useable BlockSize:108; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 120; Useable BlockSize:116; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 128; Useable BlockSize:124; Allocated BlockCount:2; Reserved AddressSpace:29488
Internal BlockSize: 136; Useable BlockSize:132; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 144; Useable BlockSize:140; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 152; Useable BlockSize:148; Allocated BlockCount:1; Reserved AddressSpace:29488
Internal BlockSize: 160; Useable BlockSize:156; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 176; Useable BlockSize:172; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 192; Useable BlockSize:188; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 208; Useable BlockSize:204; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 224; Useable BlockSize:220; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 240; Useable BlockSize:236; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 256; Useable BlockSize:252; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 272; Useable BlockSize:268; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 288; Useable BlockSize:284; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 304; Useable BlockSize:300; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 320; Useable BlockSize:316; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 352; Useable BlockSize:348; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 384; Useable BlockSize:380; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 416; Useable BlockSize:412; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 448; Useable BlockSize:444; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 480; Useable BlockSize:476; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 528; Useable BlockSize:524; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 576; Useable BlockSize:572; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 624; Useable BlockSize:620; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 672; Useable BlockSize:668; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 736; Useable BlockSize:732; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 800; Useable BlockSize:796; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 880; Useable BlockSize:876; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 960; Useable BlockSize:956; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1056; Useable BlockSize:1052; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1152; Useable BlockSize:1148; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1264; Useable BlockSize:1260; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1376; Useable BlockSize:1372; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1504; Useable BlockSize:1500; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1648; Useable BlockSize:1644; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1808; Useable BlockSize:1804; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1984; Useable BlockSize:1980; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2176; Useable BlockSize:2172; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2384; Useable BlockSize:2380; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2608; Useable BlockSize:2604; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2608; Useable BlockSize:2604; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2608; Useable BlockSize:2604; Allocated BlockCount:0; Reserved AddressSpace:0

Allocated Medium Block Count: 0
Total Allocated Medium BlockSize: 0
Reserved Medium BlockAddress Space: 868384
Allocated Large Block Count: 0
Total Allocated Large BlockSize: 0
Reserved Large BlockAddress Space0

Grüße
TurboMagic

[Codehunter]

Nimm doch mal GetMem statt New. Da kannst du die Größe explizit angeben.

[TurboMagic]

Zitat von Codehunter:

Nimm doch mal GetMem statt New. Da kannst du die Größe explizit angeben.

Danke für den Tipp, haben wir aber auch schon durch.
Die Frage ist gerade eher, warum die selbe Datenstruktur im einen Projekt 12 Byte schluckt und
im realen Projekt, ohne dass man im Code etwas anders macht, mehr als 1 KB schluckt.

Mich würde interessieren, wohin Peter's Spur führt und was man da tun könnte.
Wer verstellt diese Speichermanager Eigenschaften?

Das richtige Projekt benutzt außer Delphi's RTL/VCL auch noch JVCL Komponenten und das VST,
aber die sollten doch auch nicht den Speichermanager verstellen?!

[Neutral General]

Hab grad mal geschaut.
New ist am Ende in der .exe auch einfach nur ein GetMem. Das sollte also keinen Unterschied machen (außer Delphi glaubt in deinem Projekt, aus welchem Grund auch immer, dass dein Record 4KB groß ist). Falls das beim Debuggen auch auftritt kannst du aber theoretisch mal auf das new einen Breakpoint machen und dir das ganze im CPU-Fenster anschauen.

Delphi-Quellcode:

var testByteArr: PByteArray;
begin
  New(testByteArr);

CPU-Fenster:

Code:

Unit3.pas.156: New(testByteArr);
0064E055 B800040000       mov eax,$00000400 <---
0064E05A E81D8EDBFF        call @GetMem
0064E05F 8945E4           mov [ebp-$1c],eax

Da kannst du leicht erkennen wie viel Speicher er für dein Record tatsächlich reserviert.

[Codehunter]

Es gibt ja noch tausend weitere Möglichkeiten. Zum Beispiel ein record helper mit Inline-Methoden, der in einer Unit liegt die nur von einem Projekt eingebunden wird. Denn soweit ich die Eingangsfrage bei der Hitze verstehe, geht es ja nicht um das Ergebnis eines SizeOf() sondern um den Speicherverbrauch des ganzen Prozesses.

[Sherlock]

Mir ist klar, folgendes wird als Rat in der Regel abgelehnt, also bitte nicht böse werden, ist ja auch nur ein Testballon:
Ich würde das jetzt mal ganz pragmatisch sehen: Weiter Zeit vergeuden mit dem Versuch alten Code zu verwenden, oder einfach auf eine Klasse umsatteln? Zeiger sind so... 80er Jahre.

Sherlock

[Codehunter]

Zitat von Sherlock:

Mir ist klar, folgendes wird als Rat in der Regel abgelehnt, also bitte nicht böse werden, ist ja auch nur ein Testballon:
Ich würde das jetzt mal ganz pragmatisch sehen: Weiter Zeit vergeuden mit dem Versuch alten Code zu verwenden, oder einfach auf eine Klasse umsatteln? Zeiger sind so... 80er Jahre.

So ganz Unrecht hast du damit nicht. Man denkt gemeinhin, es gäbe gewaltige Performanceunterschiede. Tatsächlich aber sind Klassen (und generische Listen) unter bestimmten Szenarien sogar weitaus leistungsfähiger. Ich hatte einen Fall, wo ich bei Schleifen über Oldschool-Record-Listen eine Laufzeit von 60 Sekunden hatte und nach dem Umbau auf Klassen und TDictionary<key, myobject> eine Laufzeit von 4,5 Sekunden.

Und jedem Byte Speicherverbrauch nachzujagen ist auch vergeudete Müh. RAM ist das billigste und am einfachsten zu erweiternde Glied in der ganzen Problemkette.

[TurboMagic]

Eine weitere Erkenntnis:

Der Aufruf von New springt nach GETMEM.INC und zwar in diese Routine:

Delphi-Quellcode:

function SysGetMem(Size: NativeInt): Pointer;
asm
{$ifdef CPU386}
{---------------32-bit BASM SysGetMem---------------}
  {On entry:
    eax = ASize}
  {Since most allocations are for small blocks, determine the small block type
   index so long}
  lea edx, [eax + BlockHeaderSize - 1]
  shr edx, 3
  {Is it a small block?}
  cmp eax, (MaximumSmallBlockSize - BlockHeaderSize)

Im Falle des funktionierenden Testprogramms wird nach der lea edx... Zeile shr edx, 3 ausgeführt.
Im Falle des nicht funktionierenden Programms, springt lea zurück nach
function _GetMem(Size: NativeInt): Pointer; von wo aus mal MemoryManager.GetMem aufgerufen
worden war.

Also Frage: was veranlasst lea zurück zu springen, anstatt weiter zu laufen.
Im funktionierenden Testprogramm ist [eax + BlockHeaderSize - 1] = 13 und im anderen
ist eax = 10 und BlockheaderSize = 4, was ja genau das selbe ist. Wir können nur edx da nicht mehr
prüfen, da dann schon der Sprung erfolgt ist.

Grüße
TurboMagic

[peterbelow]

Zitat von TurboMagic:

Eine weitere Erkenntnis:

Der Aufruf von New springt nach GETMEM.INC und zwar in diese Routine:

Delphi-Quellcode:

function SysGetMem(Size: NativeInt): Pointer;
asm
{$ifdef CPU386}
{---------------32-bit BASM SysGetMem---------------}
  {On entry:
    eax = ASize}
  {Since most allocations are for small blocks, determine the small block type
   index so long}
  lea edx, [eax + BlockHeaderSize - 1]
  shr edx, 3
  {Is it a small block?}
  cmp eax, (MaximumSmallBlockSize - BlockHeaderSize)

Im Falle des funktionierenden Testprogramms wird nach der lea edx... Zeile shr edx, 3 ausgeführt.
Im Falle des nicht funktionierenden Programms, springt lea zurück nach
function _GetMem(Size: NativeInt): Pointer; von wo aus mal MemoryManager.GetMem aufgerufen
worden war.

Also Frage: was veranlasst lea zurück zu springen, anstatt weiter zu laufen.
Im funktionierenden Testprogramm ist [eax + BlockHeaderSize - 1] = 13 und im anderen
ist eax = 10 und BlockheaderSize = 4, was ja genau das selbe ist. Wir können nur edx da nicht mehr
prüfen, da dann schon der Sprung erfolgt ist.

Grüße
TurboMagic

Da ist was oberfaul. LEA ist keine Sprunganweisung, sie lädt einfach eine Addresse in ein Register. Wenn danach die nächste Anweisung nicht ausgeführt wird steht da im binären Kode nicht die Anweisung, die laut Source da stehen sollte, sondern was anderes, z. B. ein ret. PLaziere einen Breakpoint möglichst nahe an der lea Anweisung (weis nicht ob das direkt in einem include file geht) und sie dir den Disassembly view an.

[TurboMagic]

@Peter: Das untersuchen wir morgen.
Kollege hat auch schon Compilereinstellungen verlgichen, hat aber auch nichts gebracht.

Konntest du aus unseren Speichermanager Statuswerten noch etwas heraus lesen?

Bis vor kurzem waren diese PMyRegister records in einem Array of PMyRegister, da wir jetzt aber
diverse Lücken in den Registern bekommen, wollten wir das auf das Dictionary umstellen.

Als es noch das Array war, gab's keine Speicherprobleme.