Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

[Zacherl]

Zitat von Jim Carrey:

Design Your Delphi Program in a Way That it Keeps its Memory Usage in Check

Der Punkt mit den Forms ist gut, aber mit SetProcessWorkingSetSize die Pages zwangsweise auslagern zu wollen ist in meinen Augen großer Schwachsinn. Windows macht das nämlich ganz von alleine, wenn die betroffene Page einige Zeit lang nicht mehr verwendet wurde. Greift das Programm irgendwann wieder darauf zu, gibt es ein Page Fault und der Windows Memory Manager läd die Seite wieder in den RAM. Da sind im Hintergrund Algorithmen aktiv, die ziemlich gute Vorhersagen treffen.

Außerdem adressiert die diese API wieder nicht das eigentliche Problem. Also nochmal: Die großen Bitmaps erfordern große zusammenhängende Speicherblöcke im virtuellen Adressraum. Die Pages auszulagern entlastet aber nicht den virtuellen Adressraum, sondern nur den physikalischen Speicher.

Deshalb kann ich auch nur nochmal empfehlen die ganze Herangehensweise mit Messen des aktuell benutzten Speichers so schnell wie möglich zu vergessen. Man kann einfach nicht zuverlässig vorhersagen ab welcher Größe ein EOutOfMemory auftreten wird. Wie gesagt kann es sogar passieren, dass dein Prozess noch kaum Arbeitsspeicher verwendet, aber dank Fragmentierung kein genügend großer zusammenhängender Block verfügbar ist. Kannst du ganz leicht testen, indem du mal 1 GiB Speicher am Stück mit GetMem anforderst. Dieser Aufruf wird bei einem 32-Bit Programm in den meisten Fällen direkt scheitern. 1 GiB in mehreren kleinen 10 MiB Blöcken anzufordern, wird dahingegen sehr wahrscheinlich Erfolg haben. Auch wirst du merken, dass dein Bitmap Tool als 64-Bit Kompilat ohne Änderung vermutlich sehr viele Bitmaps mehr laden kann. Schlussfolgerung ist, dass nicht der physikalische RAM das Limit darstellt, sondern der virtuelle Adressraum.

[Jim Carrey]

Das mit den Forms mache ich teilweise auch so. Ich erstelle komplexe Formulare erst wenn sie wirklich benötigt werden.
Das verschnellert den Programmstart und hält den Speicherverbrauch ein wenig niedriger.
Hat einzig den Nachteil der Usability im Sinne von "Wenn ich da drauf klicke, soll sofort was passieren" - ist dann eben nicht der Fall.

[Bambini]

Zitat von Jim Carrey:

Das mit den Forms mache ich teilweise auch so. Ich erstelle komplexe Formulare erst wenn sie wirklich benötigt werden.
Das verschnellert den Programmstart und hält den Speicherverbrauch ein wenig niedriger.
Hat einzig den Nachteil der Usability im Sinne von "Wenn ich da drauf klicke, soll sofort was passieren" - ist dann eben nicht der Fall.

... das wäre doch eine schöne Aufgabe für einen Hintergrund-Thread.

[Benmik]

Jetzt habe ich Zacherls Vorschlag implementiert. Funktioniert auch. Aufgrund der Streams kann die Größe der Bitmaps jetzt genau angegeben werden. Der Taskmanager - der ja augenscheinlich erschütternd unzuverlässig ist - zeigt nun statt 500 MB nur noch 180 MB an.
Die ganze Geschichte läuft aber merklich langsamer ab als mit den direkt gespeicherten Bitmaps. Die Erstellung der Bitmaps/Streams ist in asychrone Threads ausgelagert, auch damit scheint es Probleme zu geben, das Programm hängt sich bei forcierter Belastung auf ("forcierte Belastung" heißt, ich halte die Weiter-Taste gedrückt und nudle 100 Bilder durch, dadurch müssen pausenlos Bilder geladen, gelesen und verworfen werden). Hab's jetzt aber noch nicht richtig handoptimiert, mal sehen.

[Bambini]

Zitat von Benmik:

Jetzt habe ich Zacherls Vorschlag implementiert. Funktioniert auch. Aufgrund der Streams kann die Größe der Bitmaps jetzt genau angegeben werden. Der Taskmanager - der ja augenscheinlich erschütternd unzuverlässig ist - zeigt nun statt 500 MB nur noch 180 MB an.
Die ganze Geschichte läuft aber merklich langsamer ab als mit den direkt gespeicherten Bitmaps.

Nun ja, der Stream liegt damit jetzt nicht mehr im RAM sondern alle auf der Platte. Auch wenn Windows hierbei einiges puffert. So schnell wie RAM ist eine Platte nie

[Benmik]

Laut Zacherl müsste das alles im RAM liegen.

[Bambini]

Zitat von Benmik:

Laut Zacherl müsste das alles im RAM liegen.

wenn du diesen Code verwendest:

Delphi-Quellcode:

 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));

dann nicht.

[Zacherl]

Zitat von Benmik:

Laut Zacherl müsste das alles im RAM liegen.

Zitat von Bambini:

Zitat von Benmik:

Laut Zacherl müsste das alles im RAM liegen.

wenn du diesen Code verwendest:

Delphi-Quellcode:

 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));

dann nicht.

Beachte das FILE_ATTRIBUTE_TEMPORARY Flag. Solange dem System genug freier physikalischer zur Verfügung steht und nichts ausgelagert werden muss, befindet sich die Datei tatsächlich komplett im RAM.

Zitat von Benmik:

Der Taskmanager - der ja augenscheinlich erschütternd unzuverlässig ist - zeigt nun statt 500 MB nur noch 180 MB an.

Wie gesagt, der Taskmanager zeigt mit dem WorkingSet nur den momentan tatsächlich physikalisch verwendeten Speicher des Prozesses an. Also exklusive ausgelagerter Pages. Daten, die du in den FileCache lädst sind darin auch nicht enthalten.

Zitat von Benmik:

Die ganze Geschichte läuft aber merklich langsamer ab als mit den direkt gespeicherten Bitmaps. Die Erstellung der Bitmaps/Streams ist in asychrone Threads ausgelagert, auch damit scheint es Probleme zu geben, das Programm hängt sich bei forcierter Belastung auf ("forcierte Belastung" heißt, ich halte die Weiter-Taste gedrückt und nudle 100 Bilder durch, dadurch müssen pausenlos Bilder geladen, gelesen und verworfen werden). Hab's jetzt aber noch nicht richtig handoptimiert, mal sehen.

Tatsächlich haben auch diese speziellen Streams einen Performance Nachteil gegenüber der direkten Speicherung im RAM. Das liegt mitunter daran, dass Windows die Dateien im Filesystem "simuliert" und auch Eigenschaften wie die letzte Zugriffszeit etc. jeweils aktualisiert. Normalen FileStreams sind sie aber trotzdem noch weit überlegen.

Optimieren könntest du noch, indem du nach dem Laden des ersten Bildes im Hintergrund schon anfängst Nummer zwei (und evtl. danach noch Nummer 3) zu laden, etc. Sind sicher noch einige Verbesserungen drinnen.

[t.roller]

Schon mal an RAMDisk gedacht?

[Benmik]

Zitat von Zacherl:

Optimieren könntest du noch, indem du nach dem Laden des ersten Bildes im Hintergrund schon anfängst Nummer zwei (und evtl. danach noch Nummer 3) zu laden...

Das geschieht ja mit den asynchronen Threads, und da ich einen Threadpool mit MaxThreads := 2 * System.CPUCount; verwende, werden sogar alle BMP gleichzeitig geladen (und geht bei einer SSD richtig schnell, bei einer normalen Festplatte ist das eher kontraproduktiv). Dieses Laden geht bei Bitmaps viel schneller. Aber daran könnte ich wohl noch schrauben.

RAMDisk sieht sehr interessant aus, ist für meine Anwendung aber eher nichts (müsste erst eingerichtet werden, der Platzbedarf ändert sich dauernd mit den Einstellungen und der Größe der Bitmaps usw.). Aber für andere Sachen wäre das vielleicht wirklich interessant!

PS:
Ich habe jetzt in einer Schleife 100 Bilder einzeln geladen, dekomprimiert, in den Stream geladen und wieder freigegeben. Das dauerte etwa 37 Sekunden, also eine drittel Sekunde pro Bild. Das Wiederauslesen des Streams und Laden in ein Bitmap verlängerte die Prozedur um 5 Sekunden, also eine Zwanzigstelsekunde je Bitmap. Da scheint mir kaum Potenzial für Verbesserungen zu sein. Ich gucke mir nochmal das Management der Threads an.

PPS:
Das RAM-Disk-Tool ImDisk findet man jetzt hier, oder besser noch bei Sourceforge mit Konfigurator.

PPPS:
Von der RAM-Disk aus läuft der Prozess mit den 100 Bildern in 35 (!) Sekunden. Das scheint mir kein echtes Optimierungspotenzial.