kleine Lücken im Heap optimal verwenden?

[BrightAngel]

Hallo liebe DP!
Ich bin gerade auf etwas gestoßen, das mich etwas verwirrt.
Wenn ich diesen Code ausführen lasse, und ich die Messageboxen auswerte, dann komme ich zu dem Ergebnis, dass das neue Byte, das ich mir hole, hinten in nagelneuem Speicher angesetzt wird.
(In der zweiten MessageBox ist FreeSmall=TotalFree dagegen FreeBig, Unused sind 0)
Komischerweise gibt es beim erneuten Aufruf des Codes im Selben aufruf wieder die ursprüngliche anzahl.
Woran liegt das? Wie kann ich die "FreeSmall" Blöcke ausnutzen? Bin ich vlt. völlig auf dem Holzweg und diese Methode ist gar nicht geeignet zur analyse des heaps???

Hier der Code, schonmal danke im Vorraus fürs Helfen.

Delphi-Quellcode:

var
  HeapStatus:THeapStatus;
  buf:PByteArray;
begin
  HeapStatus:=getHeapStatus;
  with HeapStatus do
    ShowMessage('TotalAddrSpace :'+IntToStr(TotalAddrSpace)+#13+
    'TotalUncommitted :'+IntToStr(TotalUncommitted)+#13+
    'TotalCommitted :'+IntToStr(TotalCommitted)+#13+
    'TotalAllocated :'+IntToStr(TotalAllocated)+#13+
    'TotalFree :'+IntToStr(TotalFree)+#13+
    'FreeSmall :'+IntToStr(FreeSmall)+#13+
    'FreeBig :'+IntToStr(FreeBig)+#13+
    'Unused :'+IntToStr(Unused)+#13+
    'Overhead :'+IntToStr(Overhead)+#13+
    'HeapErrorCode :'+IntToStr(HeapErrorCode));
  buf:=AllocMem(1);
  HeapStatus:=getHeapStatus;
  with HeapStatus do
    ShowMessage('TotalAddrSpace :'+IntToStr(TotalAddrSpace)+#13+
    'TotalUncommitted :'+IntToStr(TotalUncommitted)+#13+
    'TotalCommitted :'+IntToStr(TotalCommitted)+#13+
    'TotalAllocated :'+IntToStr(TotalAllocated)+#13+
    'TotalFree :'+IntToStr(TotalFree)+#13+
    'FreeSmall :'+IntToStr(FreeSmall)+#13+
    'FreeBig :'+IntToStr(FreeBig)+#13+
    'Unused :'+IntToStr(Unused)+#13+
    'Overhead :'+IntToStr(Overhead)+#13+
    'HeapErrorCode :'+IntToStr(HeapErrorCode));
  FreeMem(buf);
end;

Gruß, Brighty

[himitsu]

zuerst: Welche Delphi-Version?

Irgendwann wurde standardmäßig FastMM in Delphi eingeführt und damit gibt diese Funktion keine guten, bzw. leicht falsche Ergebnisse zurück.



Und machen kannst du nichts, da sich der Speichermanager von außen nicht geziehlt steuern läßt.

[BrightAngel]

ich benutze D7
Was mich an diesen Ergebnissen auch wundert: Wie viel Mist(???) wird denn da von den Units System, SysUtils bzw der Code den man nie zu Gesicht bekommt auf dem Heap belegt und wieder freigegeben?
Irgendwie wundert es mich, dass es so fragmentiert ist und das kurz nach programmstart.
Brighty

[Jaynder]

Ich würde mich an deiner Stelle um die Heap-Verwaltung gar nicht mehr kümmern, FastMM erledigt das perfekt. Wenn du FastMM.pas zusätzlich explizit verwendest, bekommst du auch noch Meldungen über Speicherlecks usw.

[himitsu]

OK, da gibt es noch kein FastMM.
(FastMM hat 'ne etwas andere Speicheraufteilung und versucht dann seine Speicherveraltung auf dieses Funktionsergebnis umzurechnen)

Warum so Fragmentiert:
- erstmal passiert beim Programmstart schon sehr viel (Speicher reservieren, verändern und auch freigeben) ... da müssen Lücken entstehen

- und dann wird Speicher in Gruppen reserviert, wovon erstmal nicht gleich alles belegt wird und somit frei bleibt

> große Speicherblöcke
> kleine Speicherblöcke
> sehr große Speicherblöcke

> wenn jetzt beim MM Speicher angefordert wird, dann versucht dieser entsprechend der gewünschten Größe diesen irgendwo einzuordnen


@Jaynder:
OK, in D7 kann er FastMM nachrüsten, ABER:
- FastMM verwaltet den Speicher "besser"/schneller
- erzeugt dabei aber auch eine stärkere Fragmentierung und mehr Lücken,
also genau das Gegenteil des Gewünschten.

Aber wie schon gesagt: Kümmere dich nicht darum ... solange kein "unausweichliches" OutOfMemory eine andere Speicherverwaltung erfordert.

[Jaynder]

@himitsu

Zitat:

- erzeugt dabei aber auch eine stärkere Fragmentierung und mehr Lücken,
also genau das Gegenteil des Gewünschten.

das stimmt so nicht. Genau die Fragmentierung wird absolut verhindert, weil nicht mehr byte-genaue Blöcke reserviert werden, sondern nur noch feste "gerade" Blöcke (z.b. 32er, 64er, 96er) usw und die jeweils in einer eigenen Liste verwaltet werden. Das durch den Verschnitt generell Lücken entstehen und so der Speicher nicht zu 100% ausgenutzt wird, kann man bei heutigen Speichergrößen jedoch leicht verschmerzen.

[himitsu]

Und genau das erzeugt auch einen gewissen Verlust, da so eben fast immer mehr Speicher belegt wird, als nötig.

PS: auch Delphis alter MM reservierte schon in Blöcken/Gruppen und nicht alles Bytegenau.
(OK, abgesehn von "großen" Speicherblöcken, aber da macht es auch FastMM so)


Na gut, FastMM versucht dieses Problem allerdings durch eine größere Anzahl verschiedener und feiner unterteilter Gruppen zu lösen.

[BrightAngel]

okay, danke erstmal für euren tipp mit fastmm und dn erklärungen dazu!
Wie macht das delphi dann? also wenn fastmm die erste unit in meiner uses ist, sind doch system und sysutils noch davor geladen oder???

Naja vlt sehe ich das auch etwas zu eng.
Ich habe mir jetzt halt folgendes überlegt:
ich muss in meiner Anwendung öfter Speicher anfordern und zwar so:
-Speicherblock (größe: n*sizeof(TRecordX)) wird angefordert
-TList mit n Pointern auf jeweils ein TRecordX <--die ist mein problem+
-Jetzt KANN es passieren, dass wieder ein Speicherblock wie oben angefordert wird.
-Die Liste "frisst". Nach ein Paar Zyklen ist sie zu groß für den Speicherbereich Folge: sie wird verschoben.
Dieser Bereich ist aber gerade zu Anfangs so klein, dass die zu anfordernten Speicherblöcke zu groß sind, um in die von TList freigewordenen Plätze reinzupassen. Ich habe schon mit dem Gedanken gespielt, ein gleichgroßer Speicherblock standartmäßig für diese Tlist zu verwenden, sodass er später anders verwendet werden kann, aber ist das das Gelbe vom Ei?
[EDIT1]Bzw. Wenn FastMM immer nährungsweise größere Blöcke anfordert, dann ist meine Methode ja auch Kontraproduktiv, weil bei jedem, immer fix bleibendem Block reste entstehen???[/EDIT1]

Würde es mir was bringen, wenn ich einen eigenen Heap extra dafür erschaffen würde??? also via createHeap etc?
Brighty

[himitsu]

FastMM muß die erste Unit in der DPR sein.

Gut, Delphis Speichermanager wird dann zwar dennoch in der System-Unit als Allererstes eingebunden, aber es wird erst bei der ersten Verwendung initialisiert.

Und in den Units System, SysInit und SysConst (welche ja die ersten sind) passiert aber speichertechnisch noch keinerlei Anforderung, bei deren Initialisierung.

Demnach kommt als Nächstes FastMM, biegt die Speicherfunktionen (GetMemory und Co.) auf sich um und wird dann ab da verwendet.

[BrightAngel]

Okay Vielen Dank euch Allen!
Das heißt, ich kann eigentlich mit FastFM nix verkehrt machen
Brighty