Objektliste sprengt RAM (32-bit)

[freimatz]

Ist das Problem noch offen?
Genauer als der ProcessMonitor dürfte es sein, den Speicherverbrauch direkt in deinem Code zu messe. Wir haben da:

Delphi-Quellcode:

function GetApplicationMemory(): Int64;
var
  memoryState: TMemoryManagerState;
  blockState : TSmallBlockTypeState;
begin
  GetMemoryManagerState(memoryState);
  with memoryState do begin
    Result := TotalAllocatedMediumBlockSize + TotalAllocatedLargeBlockSize;
    for blockState in SmallBlockTypeStates do
      Inc(Result, blockState.AllocatedBlockCount * blockState.UseableBlockSize);
  end;
end;

[Jens01]

Zitat:

Ist das Problem noch offen?

Ja, ich muss aber erst noch ein Testprogramm erstellen. Das kann noch ein paar Tage dauern.
Dein GetApplicationMemory kann ich aber sehr gut gebrauchen. Sowas habe ich nämlich dafür noch gesucht. Danke!

[dummzeuch]

Ein uebliches Problem ist das Vergroessern einer Liste: Sie wird immer um 25% der bisherigen Groesse vergroessert:

Delphi-Quellcode:

procedure TList.Grow;
var
  Delta: Integer;
begin
  if FCapacity > 64 then
    Delta := FCapacity div 4
  else
    if FCapacity > 8 then
      Delta := 16
    else
      Delta := 4;
  SetCapacity(FCapacity + Delta);
end;

Und in SetCapacity wird dann ReallocMem aufgerufen, was ggf. Speicher fuer eine neue Liste anfordert und dann die alten Eintraege kopiert. Das kann dann bei einer grossen Liste schnell zu Problemen fuehren.

Ach ja: MaxListSize ist MaxInt div 16

also ca. 2.000.000.000 / 16 = ca. 125.000.000

Nicht zu vergessen: Auch die Objekte selbst benoetigen Speicher und sorgen dafuer, dass er fragmentiert.

twm

[dummzeuch]

Ach ja, noch was: Wenn es bei den Strings viele Duplikate gibt, lohnt es sich evtl. diese zusammenzufuegen:

https://en.wikipedia.org/wiki/String_interning

https://sourceforge.net/p/dzlib/code...StringPool.pas

Das kann den Speicherverbrauch drastisch reduzieren.

ShortString bringt uebrigens keinen Vorteil gegenueber den standard Strings, sie verbrauchen immer 256 Bytes.

twm

[Jens01]

Das mit dem Grow is es nicht. Ich hatte schon versucht das runter zu setzen.

Zitat:

Ach ja, noch was: Wenn es bei den Strings viele Duplikate gibt, lohnt es sich evtl. diese zusammenzufuegen:

Ich speichere ja eigentlich keine Strings. Strings gehören zu den Selektoren.
Ich speichere Werte mit TAnyValue eine Art TValue. Das Ding habe ich gerade im Verdacht.

[Jens01]

Zitat:

Nicht zu vergessen: Auch die Objekte selbst benoetigen Speicher und sorgen dafuer, dass er fragmentiert.

Ja genau. Deswegen habe ich eigentlich gefragt, ob das an dem Objekt liegen kann. Kann so eine Fragmentierung so viel den Speicher aufblähen, wenn die Daten selbst eigentlich nur eine sehr kleine Größe haben?

[Jens01]

Soo..
Ich habe das jetzt noch mal getestet. Es scheint wirklich an den Strings zu liegen. 3 Stück habe ich davon, kann aber nur ein String durch einen Integer ersetzen. Dies TAnyValue ist unschuldig!

Das Objekt durch ein Record zu ersetzen, bringt ca 20% an Speichereinsparung. Beim Durchsuchen der Liste wird dann aber mehr als das Doppelte an Zeit benötigt.

Ich glaube, ich muss meine Architektur noch mal überdenken....
Oder auf 64-Bit umstellen und Ram kaufen.
Wahrscheinlich beides.