nicht angemeldet
Das Problem hierbei ist, wie auch bei der Verwendung von Arrays oder von planen Objekten, dass solange die entsprechende Datenstruktur nicht selbst von der Garbage Collection abgeräumt oder das Programm beendet wird, alle von der Klasse erzeugten Instanzen und die dazugehörigen Datenobjekte im Speicher verbleiben, sofern man die Referenzen nicht von Hand wieder entfernt. Das kann abhängig von der Anzahl der von der Klasse erzeugten Instanzen und der Menge der hinterlegten Daten durchaus zum Problem werden.
Wenn Daten mit Objekten zu assoziieren sind ohne sie in den Objekten selbst zu hinterlegen, dann sollte also besser die Verwendung einer WeakMap in Betracht gezogen werden. Wie der Name bereits andeutet, werden hier die Referenzen auf die als Schlüssel verwendeten Objekte schwach gehalten, das heißt, wenn außer dem Eintrag in der WeakMap keine andere, starke Referenz auf ein entsprechendes Objekt mehr besteht, dann wird der Eintrag aus der WeakMap entfernt und das Objekt wird gelöscht, ebenso wie das assoziierte Datenobjekt, auf das nach dem Löschen des Schlüssels auch keine Referenz mehr bestehen sollte.
Guter Beitrag, danke. Ich stimme dir zu, leite aber aus daraus nicht ab, dass man WeakMaps allgemeinen Vorzug vor Maps geben sollte. Es ist ein Trade-Off zwischen Speicherbedarf und Performance. Die Garbage-Collection kann selber schnell zu einem Performance-Flaschenhals werden. Viele Performance-Optimierung konzentrieren sich deshalb darauf, die Garbage-Collection möglichst wenig zu beschäftigen. Um eine Entscheidung pro oder kontra WeakMap zu fällen hilft letztendlich nur Memory- und CPU-Profiling. Die Chrome-Dev-Tools haben die richtigen Werkzeuge dafür an Board.
Der Martin
Orlok