![]() |
AW: Maßnahmen zum Speicherverbrauch minimieren
Zitat:
|
AW: Maßnahmen zum Speicherverbrauch minimieren
Dann wäre das letztlich ein eindeutiger Schlüssel bzw. Index für einen bestimmten Eintrag - oder?
Ansonsten würden Hashkollisionen möglich sein oder in der Hashtabelle viele Plätze unbelegt bleiben müssen. Kannst Du Euren Ansatz noch etwas erklären? |
AW: Maßnahmen zum Speicherverbrauch minimieren
Zitat:
Ein Dictionary unterteilt die Key-Menge in Buckets, wo alle Elemente hineinkommen, die den gleichen Hashwert haben und such dann nur noch in diesem Bucket nach dem passenden. |
AW: Maßnahmen zum Speicherverbrauch minimieren
Naja, der Fall ist etwas speziell, in dem Fall war eine Hashfunktion machbar, weil die Strings bestimmte Bedingungen erfüllen. Teile davon konnten in die dahinterliegenden Objekte zusammengefasst werden (stell es dir wie einen Index vor), und bestimmte Teile sind ansonsten eindeutig.
|
AW: Maßnahmen zum Speicherverbrauch minimieren
Zitat:
|
AW: Maßnahmen zum Speicherverbrauch minimieren
Aaalsooo...
Unter 32bit habe ich mal 4 Varianten versucht, bis Out of Memory kam: Debug, IDE, 97.059, 1.946,2 MB Debug, EXE, 97.125, 1.947,8 MB Release, IDE, 97.498, 1.955,0 MB Release, EXE, 97.498, 1.955,2 MB Also ob Debug oder Release bzw. unter IDE-Kontrolle oder nicht spielt keine Rolle. Unter 64bit (Debug, IDE) habe ich mal 600.000 Mainobjekte erzeugt. Bei ca. 5GB hat Windows scheinbar immer Daten ausgelagert und dann wieder weitere Objekte erzeugt. Keine Ahnung, was da genau passiert. Zumindest sollte man den Speicherverbrauch wohl nicht so hoch treiben, da die Anwendung sonst ausgebremst wird. (Alles nur mein erster Eindruck.) Dann bin ich zurück auf 32bit und habe die gleichen Strings durch Referenzen auf existierende Interfaces ersetzt und dachte, das würde eine deutlich höhere Anzahl von MainObjekten ermöglichen. Das Gegenteil war der Fall. Es waren nur noch 92.539!? Kann sein, dass es heute zu spät für mich ist. Das schaue ich mir am WE noch näher an. Aber ich habe mir auch mal die gesamten Datenobjekte ausgeben lassen 92.480 Mainobjekte -> 1.942.058 Gesamtobjekte Die Mainobjekte haben also durchschnittlich 20 Unterobjekte und insgesamt sind es fast 2Mio. Das sind also schon ein paar, aber die Speicherbedarfsreduzierung bleibt auf jeden Fall ein Ziel von mir. Dann bin ich zurück zu den Strings von vorher (alte Sicherung verwendet). Die Objekte blieben bei 92540->1943318 obwohl es am Anfang ja 97.000 waren. Nach einem PC-Neustart waren es noch weniger: 91348->1918214 Also die Gründe für diese Schwankungen kann ich mir nicht erklären. Vielleicht muss man einfach damit leben. Warum die Änderung auf Objektreferenzen statt den Strings nichts brachte oder sogar kontraproduktiv war, ist mir rätselhaft. (Ein Fehler meinerseits kann hier ggf. allerdings auch möglich sein.) |
AW: Maßnahmen zum Speicherverbrauch minimieren
Tja, ich habe dir gezeigt wie man den Speicherbedarf bei vielen gleichen Strings groß macht oder klein hält.
Da du nicht zeigen möchtest, wie du das konkret umsetzt, wirst du dich darum selber kümmern müssen. Eins kann ich aber sagen: Das mit den Interfaces und den Strings ist von hinten nach vorn dreimal gedreht und einmal hochgeworfen. Ein String wird doch schon quasi wie ein Interface behandelt (siehe mein Beispiel). Und du bastelst da nochmal ein Interface drum herum und das anscheinend auch noch falsch ... |
AW: Maßnahmen zum Speicherverbrauch minimieren
Ein Auszug wir schwierig und durch das ganze Projekt wirst Du Dich nicht wühlen wollen.
Ich nehme mir am WE dafür Zeit. |
AW: Maßnahmen zum Speicherverbrauch minimieren
Zitat:
Es geht doch nur um das BO und die Liste mit den Eigenschaften und die Stelle, wo so ein BO erzeugt wird. Da ist der Speicherfresser. Warum sollte ich mir etwas anschauen, wo du bunte Striche malst? |
AW: Maßnahmen zum Speicherverbrauch minimieren
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:28 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz