Memory Mapped Files bei vielen (großen) Bitmaps

[Schwedenbitter]

Hallo,

ich bin dabei, ein Programm für eine Dokumentenverwaltung zu schreiben. Über einen Seitenscanner werden große Datenmengen geliefert. Diese wollte ich irgendwo auslagern, um den RAM zu schonen. Bei 300 dpi in DINA-A4 sind das 16 MB pro Seite. Zusätzlich soll der Benutzer die Möglichkeit haben, Kontrast und Kompressionsstärke bei jpg anzupassen.
Aktuell "löse" ich das über ein simples TBimap.SaveToFile(); . Bei/vor dem Verarbeiten lade ich dann das betreffende Bitmap zurück. Dabei zeigt sich die HDD - wer hätte das auch anders gedacht - als Flaschenhals.

Dadurch kamen MMF ins Spiel. Diese bleiben auch im RAM und werden erst (in der Auslagerungsdatei?) ausgelagert, wenn dieser voll ist - sofern ich das System richtig verstanden habe.
Allerdings kam mir dabei die Überlegung, dass Windows doch sowieso in die Auslagerungsdatei schreibt, wenn der RAM aufgebraucht ist. So richtig sehe ich also keinen Vorteil. Es kommt hinzu, dass MMF programmtechnisch aufwendig sind, insbesondere weil die Größe beim Schreiben/Lesen feststehen muss und diese von Bitmap zu Bitmap unterschiedlich ist.

Ich bin jetzt also am Grübeln, ob ich mir das antue und wüsste gern Eure fachkundige Meinung dazu.

Wie es funktioniert, habe ich mir erarbeitet und auch ein klitzekleine Funktionieren Class von TBitmap abgeleitet. Bevor ich aber weiter mache, stelle ich lieber mal diese Frage.
Falls ich hier falsch bin und die Frage eher zu "Win32/Win64 API (native code)" gehört, kann das bitte mal der Moderator erledigen. Danke.

[matashen]

Also ich würde da noch überlegen die Daten als PNG zwischen zu speichern oder als Endformat zu nehmen. PNG ist in Delphi integriert, hat gute Kompression und Komprimiert verlustfrei. Dadurch speicherst du wesentlich schneller als Bitmap. musst nur TPNGImage in die uses Klausel schreiben, dann geht das Format mit den TGraphic Schnittstellen.

Gruß Matthias

[himitsu]

SaveToFile speichert zuerst in den WindowsFileCache und Windows schiebt es auf die Festplatte. Es bleibt dann auch im Cache, so lange wie möglich.
Wenn der RAM reicht, wird die Festplatte kein Flaschenhals sein.

MMF mit Dateianbindung, mappt es in den "physischen" RAM, wenn der Platz reicht und der REST bleibt auf der Festplatte. (in der Datei)
Bei MMF ohne Datei bleibt es im physischen RAM oder landet in der Auslagerungsdatei (Festplatte).

Speicherseiten im Virtuellen Arbeitsspeicher bleiben immer da, wo man sie hingemappt hat, aber aber ob sie "aktuell" im physischen Speicher geladen sind, hängt davon ab, ob man darauf zugreift und ob genügend physischer Speicher zur Verfügung steht.

Fazit: Du kannst nur durch MMF rein garnichts verbessern.
Außer zusätzlich zum physischen RAM auch noch deinen Virtuellen vollzumüllen (PS: Bei einem 32-Bit-Programm hast du da nur maximal 2 bis 3 GB RAM zur Verfügung)

Und dein Flaschenhals ist eigentlich der zu geringe Arbeitsspeicher.



PS: PNG hat zwar eine "gepackte" Version des Bildes, aber es existiert auch intern eine entpackte Version (Bitmap), vorallem wenn man das PNG fisch erstellt hat (neu generiert und bemalt) oder darin rummalt.
TPngImage.GetHeader{TChunkIHDR}.FreeImageData

[matashen]

Hi Himutsu,

das mit PNG im RAM ist korrekt,

nur beim schreiben von/zu der Festplatte ist ein wesentlicher Unterschied, es erreicht auch ohne verluste nahezu die Packungsdichte von JPG, vor allem bei gescannten Seiten wo viel Identische Farben sind. Bei Fotos ist die Packungsdichte nicht ganz so gut wie im JPG, dafür aber immer noch verlustfrei - und in Bezug auf Festplattenplatz/Schreibmenge/Lesemenge immer noch besser als Bitmaps auf die Platte zu schieben.

[jobo]

Hast Du mal überlegt, ob Du den Farbraum reduzieren kannst?
Sollte bei Dokumentenscans unproblematisch sein oder?
Greyscale 256 reduziert bei BMP den Speicherbedarf enorm, ebenso bei PNG.
JPG ist m.E. unschlagbar, zumindest bei "natürlichen" Bildern wie einem scheinbar weißen Blatt Papier, das wahrscheinlich mehr Weißabstufungen hat als die Eskimos Schneesorten kennen. Bei Screenshots bspw. sind es meist viel weniger Farben, da eignet sich m.E. PNG besser wegen der geringen Kompressionsartefakte bei starkem Kontrast.

[himitsu]

Meine Aussage bezog sich vorallem auf viele PNG im RAM, anstatt der Bitmap.
Zur Laufzeit brauchen gepackte Formate (PNG, JPEG usw.) oft mehr Platz, als ein Bitmap, vorallem wenn sie als Zwischenspeicher ein Bitmap benutzen.

[Blup]

Braucht der Anwender wirklich 300DPI für eine Dateivorschau des Dokuments?
Speichere eine verkleinerte Version als JPG, die standardmäßig zur Voransicht geladen wird.
Erst wenn der Anwender zur Lupe greift, würde ich die volle Auflösung laden.
Oder in einem Thread im Hintergrund, wenn fertig wird umgeschalten.