Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

[Jim Carrey]

Zitat:

Aber Gottsakra, warum funktioniert denn die Speichermessung nicht?!

Funktioniert mein kopierter Code nicht?

[Zacherl]

Wie wäre es denn hiermit:

Delphi-Quellcode:

type
  TMemoryFileStream = class(THandleStream)
  public
    constructor Create;
    destructor Destroy; override;
  end;

{ TMemoryFileStream }

constructor TMemoryFileStream .Create;
begin
  inherited Create(CreateFile(PChar(TPath.GetTempFileName), GENERIC_READ or GENERIC_WRITE,
    0, nil, CREATE_ALWAYS, FILE_ATTRIBUTE_TEMPORARY or
    FILE_ATTRIBUTE_NOT_CONTENT_INDEXED or FILE_ATTRIBUTE_HIDDEN or FILE_FLAG_DELETE_ON_CLOSE, 0));
end;

destructor TMemoryFileStream .Destroy;
begin
  if (FHandle <> INVALID_HANDLE_VALUE) then
  begin
    FileClose(FHandle);
  end;
  inherited Destroy;
end;

Du zeigst ja immer nur ein Bild gleichzeitig an, so wie ich das verstanden habe. Dieses Bild lädst du von seinem originalen Speicherort, decodierst es ggfls., so dass du die Bilddaten als TBitmap vorliegen hast und zeigst es dann an. Sobald der User jetzt das nächste Bild anzeigen will, speicherst du das aktuelle Bild mit der von mir geposteten Stream-Klasse, gibst das TBitmap frei und wiederholst die Aktionen zum Anzeigen des neuen Bildes. Soll nun eines der vorherigen Bilder angezeigt werden, lädst du das TBitmap einfach wieder aus dem Stream. Diese Stream-Klasse ist ziemlich performant, da sie den Windows File-Cache verwendet. Es sieht zwar so aus, als ob die Daten in einer temporären Datei gespeichert werden, aber so lange Windows global genug freien RAM zur Verfügung stehen hat, bleiben die Daten dort im Cache. Zugriffe auf die Festplatte hast du so also im Optimalfall gar nicht und als Bonus managed Windows den kompletten Speicher für dich. EOutOfMemory Exceptions wären damit auf jeden Fall Geschichte.

[t.roller]

Very Large Bitmap Experiment
http://www.efg2.com/Lab/Graphics/VeryLargeBitmap.ZIP

[Benmik]

Süß! Windows 95! Delphi 3! Toll!
Aber auch die maximale Größe, die das Programm annimmt, zwingt mein System nicht in die Knie.
Projekt öffnen und modifizieren habe ich mir allerdings gespart.

[Benmik]

Zitat von Jim Carrey:

Funktioniert mein kopierter Code nicht?

Den Code kannte ich schon von diversen stackoverflow-Diskussionen, aber misst der nicht nur den aktuellen Prozess und nicht den Gesamtspeicher, den die komplette Anwendung verbraucht?

Zitat von Zacherl:

Wie wäre es denn hiermit:

Das ist ja interessant! Das werde ich mal ausprobieren.

[Bambini]

Zitat von Benmik:

Zitat von Jim Carrey:

Funktioniert mein kopierter Code nicht?

Den Code kannte ich schon von diversen stackoverflow-Diskussionen, aber misst der nicht nur den aktuellen Prozess und nicht den Gesamtspeicher, den die komplette Anwendung verbraucht?

Dann fragt doch beim FastMM4 Memory Manager nach, wie viel deine Anwendung gerade verwendet:

Delphi-Quellcode:

var
  LMem : TMemoryManagerUsageSummary;
begin
  GetMemoryManagerUsageSummary(LMem);
  Caption := LMem.AllocatedBytes.ToString + ' Bytes';

[t.roller]

How Much Memory Is Your Delphi Program Occupying?

[Zacherl]

Zitat von t.roller:

How Much Memory Is Your Delphi Program Occupying?

Der Artikel ist nebenbei erwähnt inkorrekt. Memory Leaks kann man nicht zuverlässig über die WorkingSetSize detecten. Ich verweise auf folgenden Beitrag: http://stackoverflow.com/a/1986486. Die WorkingSetSize umfasst nämlich nur den Speicher des Prozesses, der momentan tatsächlich im physikalischen RAM in Verwendung ist. Grade bei Memory Leaks wird man auf die "vergessenen" Speicherstellen nie wieder zugreifen, weshalb Windows die betroffenen Pages früher oder später auslagert. Die WorkingSetSize verringert sich danach wieder um die ausgelagerte Datenmenge, das Memory Leak ist aber trotzdem vorhanden und verschwendet Platz im virtuellen Adressbereich.

[Benmik]

Zitat von Zacherl:

Der Artikel ist nebenbei erwähnt inkorrekt.

Inkorrekt! INkorrekt !!! Wann habe ich das zum letzten Mal gelesen? Danach folgt aber "detecten"... Man weiß nicht mehr, was man denken soll.

Ich habe erstmal Benedikt Magnus' Anregung aufgegriffen und die Größe der 7 Bitmaps ermittelt: SizeOf(BMP) + Bmp.Width * Bmp.Height * (24 div 8) . Das ergab ungefähr 370 MB. Dann habe ich Bambinis Anregung umgesetzt, das ergab einen Wert von ca. 2,7 MB. Der Taskmanager zeigt ca. 500 MB. Das verstehe, wer will.

Die Umsetzung von Zacherls Hinweis wird etwas aufwändiger und dauern.

[Benedikt Magnus]

Zitat von Benmik:

Ich habe erstmal Benedikt Magnus' Anregung aufgegriffen und die Größe der 7 Bitmaps ermittelt: SizeOf(BMP) + Bmp.Width * Bmp.Height * (24 div 8) . Das ergab ungefähr 370 MB. Dann habe ich Bambinis Anregung umgesetzt, das ergab einen Wert von ca. 2,7 MB. Der Taskmanager zeigt ca. 500 MB. Das verstehe, wer will.

Bedenke, dass das Programm selbst ja auch noch Speicher braucht (plus evtl. Overhead). Außerdem wird Speicher, den das Programm einmal belegt hat, nicht unbedingt direkt wieder freigegeben.
Wenn du also eine Pauschale für das Programm selbst nimmst und dir merkst, wie viele MB an Bitmaps bisher maximal gleichzeitig im Speicher lagen, müsstest du etwas erhalten, dass garantiert unter dem Wert im Taskmanager liegt (und bei voller oder konstanter Auslastung an Bitmaps sogar nahe am Taskmanager).