AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi Delphi Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

Ein Thema von moelski · begonnen am 18. Sep 2010 · letzter Beitrag vom 16. Nov 2016
Antwort Antwort
Seite 4 von 5   « Erste     234 5   
Bambini
(Gast)

n/a Beiträge
 
#31

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 10:15
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.
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
532 Beiträge
 
Delphi 11 Alexandria
 
#32

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 15:32
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.
  Mit Zitat antworten Zitat
Bambini
(Gast)

n/a Beiträge
 
#33

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 16:13
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
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
532 Beiträge
 
Delphi 11 Alexandria
 
#34

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 17:00
Laut Zacherl müsste das alles im RAM liegen.
  Mit Zitat antworten Zitat
Bambini
(Gast)

n/a Beiträge
 
#35

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 17:43
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.
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#36

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 18:13
Laut Zacherl müsste das alles im RAM liegen.
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.

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.

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.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
t.roller
(Gast)

n/a Beiträge
 
#37

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 20:00
Schon mal an RAMDisk gedacht?
Miniaturansicht angehängter Grafiken
20140124_ramdiskwindows_write.jpg  
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
532 Beiträge
 
Delphi 11 Alexandria
 
#38

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 9. Nov 2016, 20:07
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.

Geändert von Benmik ( 9. Nov 2016 um 21:05 Uhr)
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
532 Beiträge
 
Delphi 11 Alexandria
 
#39

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 12. Nov 2016, 21:01
Ich habe jetzt eine Reihe von Versuchen durchgeführt, die die alte (Speichern von TBitmap) mit der neuen (TMemoryFileStream) Methode vergleicht, mit einem etwas zwiespältigen Ergebnis.
  • Mit TMemoryFileStream kann ich abenteuerliche Werte für die Anzahl der vorzuladenden Bilder eingeben, zum Beispiel 30 vor und 30 zurück, ohne das es knallt. Gut!!
  • Als Extremwert habe ich 99 vorzuladende Bilder eingestellt (Maximalwert). Hierbei belegt der Filecache (ich habe 8 GB RAM) laut Ressourcenmonitor etwa 6 GB, uneingeschränkt frei noch 80 MB. Das ist eindrucksvoll.
  • Das Laden und Anzeigen der Bilder dauert ziemlich zuverlässig doppelt so lange wie mit TBitmaps.
  • Dies liegt am Speichern im TMemoryFileStream. Das Laden der JPG von der SSD ist vernachlässigbar, 15 ms. Das Dekodieren der Bitmaps aus den JPG dauert sehr einheitlich etwa 170 ms.
  • Bei Methode 2 kommt nun noch das Speichern im Stream dazu. Das dauert 140 bis 170 ms, dazwischen aber immer wieder über 500 ms.
  • Das Laden mit den Bitmaps wirkt schneller und spritziger, reagibler. Das "Durchnudeln" mit gedrückter Vorwärtstaste geht richtig zügig.
Jetzt kann ich mich entscheiden, was ich will, Leistung oder Robustheit. Vermutlich ist Letzteres wichtiger.
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#40

AW: Speicherlast des Programms mittels GetMemoryManagerState - komischer Wert

  Alt 13. Nov 2016, 20:38
Mir kommt da grade noch eine Idee:

Dein größtes Problem ist ja erstmal die 2GiB Grenze des virtuellen Adressraums. Du könntest dir eine weitere (Stream-)Klasse basteln, in der du die Daten als Memory Mapped File (MSDN-Library durchsuchenCreateFileMapping, MSDN-Library durchsuchenMapViewOfFile) speicherst. Solange mindestens ein Handle auf das MMF offen ist, wird es vom System nicht gelöscht, selbst dann, wenn du den Dateiinhalt mit MSDN-Library durchsuchenUnmapViewOfFile wieder aus deinem Prozessspeicher entfernst.
Wenn du jetzt jeweils nur das aktuell geöffnete Bild mappst, hast du auch immer nur einen großen zusammenhängenden Speicherblock in deinem virtuellen Adressraum liegen und würdest zumindest diese Ursache für eine EOutOfMemory Exception eliminieren. Sollte dein physikalischer RAM irgendwann nicht mehr ausreichen, fängt Windows halt an RAM in die Auslagerungsdatei auszulagern.

Zu bedenken ist hierbei allerdings, dass du mit dieser Methode natürlich die Leistung des ganzen System beeinträchtigen kannst, wenn du den kompletten RAM mit deinen MMFs füllst. Wobei selbst hier der Overhead nicht allzu fatal sein sollte.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:40 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz