Objektliste sprengt RAM (32-bit)

[Jens01]

Hatte ich vergessen zu erwähnen: Es läuft FastMM.

Und es sind ganz sicher keine Leaks, das prüfe ich ständig.

[Jens01]

Danke für die Einschätzungen.

Die kreisen die Suche schon etwas ein. Ich werde erst einmal ein Testprojekt bauen und mich dann zurückmelden.

[Sir Rufo]

Also ohne annähernd konkrete Werte kann man so ca. Angaben überhaupt nicht bewerten.

mehrere zehntausend Objekte belegen nur ein paar KiloByte im Stream

Jedes Objekt müsste im Stream so mindestens um die 40 Byte belegen (gerechnet ohne Strings). Bei mehreren zehntausend nehme ich mal 30.000 an und komme auf 1.320.000 Byte was so 1,3 MegaByte entspricht (und das als absolutes Minimum).

Somit passen hier auch die Aussagen insgesamt logisch nicht zueinander.

Aktuell kann es also auch nur unlogische Mutmassungen geben und da passt wohl am besten 42

[himitsu]

Hab ich das überlesen, oder wurde nicht gesagt wo es knallt?

* Erstellen eines neuen Datenobjekts
* Laden der Daten, die in das neue Objekt rein sollen
* Befüllen des Datenobjekts
* Hinzufügen des Objekts zur Liste

Beim Hinzufügen muß eventuell die komplette Liste kopiert werden, wenn sich der Speicher nicht inplace vergrößern lässt,
aber für "mehrere 10000 Objekte" sollten dafür keine 150 KB an freiem zusammenhängendem Speicher nötig sein.

Festplatte ... Text als ANSI und im RAM als Unicode = doppelt so viel, plus je paar Byte für die Verwaltung/Alignment.

FastMM ... seit Delphi 2006? ist das schon eingebaut (in einer "leicht" abgespeckten Version)
Und wenn du aber eine eigene "externe" Version einbindest, dann hat ReportMemoryLeaksOnShutdown keine Wirkung, da es nur den internen FastMM steuert.
Der externe FastMM wird über seine Options.inc bedient.

[Stevie]

Callstack der Exception?

Out of memory exceptions kommen nicht nur, wenn wirklich kein Speicher mehr da ist.

[Jens01]

Zitat:

Out of memory exceptions kommen nicht nur, wenn wirklich kein Speicher mehr da ist.

Ich habe ein "System-Explorer" mitlaufen. Da kann ich eigentlich gut verfolgen, wie die Rambelegung hochläuft, wenn die Liste gefüllt wird. Ich habe das Problem zurvor auch schon eingekreist, zB indem ich Teile der Liste per Stream auf der Festplatte ausgelagert habe. Dann funktionierte es ohne Fehler. (Die Liste wird in Schüben gefüllt.)

[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