C# Geheugenbeheer van een zoekboom

[SideShow]

Hallo

Ik heb, voor de fun, een boom datastructuur gemaakt, die zich afspeelt in een bestand on disk.
Elke node bevat de byte positie in het bestand van zijn parent, van zijn linkse node, van zijn rechtste node, enz...
Ik heb wat zaken geïmplementeerd zoals zoeken, traversel, balancing, .... bij wijze van oefening.

Om de snelheid (gevoelig) op te drijven, heeft elke node, naast het byte adres van zijn gerelateerde nodes, ook een object referentie naar die nodes, die dus eigenlijk als cache werkt.

Het probleem is nu geheugengebruik. Als je een in-order-traversel doet, heb je eigenlijk gewoon elke node in memory en niks wordt opgeruimd door de GC omdat je een ref. hebt naar de root node.

Ik zoek naar manieren om het geheugengebruik omlaag te helpen.

Waaraan ik zelf denk:
- compileren als 32 bits app: zo zijn object referenties maar 32 bit ipv 64 bit
- op bepaalde momenten zelf doorhebben dat je app teveel ram gebruikt, en dan ergens een node referentie doorknippen om vervolgens manueel de GC aan te roepen (...)
- anders omspringen met het bestand op de harde schijf, zodanig dat lezen veel efficiënter gaat en mijn object referenties wegkunnen


Wellicht is vooral de laatste optie een goed idee. Zijn er hier mensen die nog andere ideeën hebben?

[RobIII]

SideShow schreef op vrijdag 15 juli 2016 @ 15:06:
Om de snelheid (gevoelig) op te drijven
[...]
Het probleem is nu geheugengebruik
[...]
Ik zoek naar manieren om het geheugengebruik omlaag te helpen.

Raar; je wil juist zoveel mogelijk in-memory hebben om de snelheid hoog te houden. Wat heb je aan je RAM als er alleen maar lucht in zit? Vullen die hap! Zoveel mogelijk!

[Gomez12]

SideShow schreef op vrijdag 15 juli 2016 @ 15:06:
Waaraan ik zelf denk:
- compileren als 32 bits app: zo zijn object referenties maar 32 bit ipv 64 bit

Nep-oplossing, want je gaat tegen lagere geheugengrenzen aanlopen.

- op bepaalde momenten zelf doorhebben dat je app teveel ram gebruikt, en dan ergens een node referentie doorknippen om vervolgens manueel de GC aan te roepen (...)

Never nooit niet manueel de GC aanroepen, en op dezelfde voet, ook niet doorhebben dat je app teveel ram gebruikt. Gewoon niet.
Wat je wel kan doen is het gewoon onderverdelen in vaste blok-groottes en dan meer of minder blokjes inlezen, maar niet on the fly beslissingen gaan nemen als je denkt dat je te weinig ram hebt.

- anders omspringen met het bestand op de harde schijf, zodanig dat lezen veel efficiënter gaat en mijn object referenties wegkunnen

Tja, wat is nu eigenlijk je probleem? Je beschrijft dat je een soort cache hebt en dat die teveel geheugen kost, dan lijkt het mij simpel : Limiteer de cache / evacueer zooi uit die cache en haal het weer van disk als het nodig is.

[HMS]

Klinkt alsof je gebruik wilt maken van WeakReferences.

[Ventieldopje]

Heb je al in kaart wat het verschil is in performance en resource gebruik (CPU / DISK / MEM) met de cache aan en uit?

Zodra je dat in kaart hebt kun je pas gaan optimaliseren lijkt mij. Nu bedenk je zelf van "het gebruikt wel veel geheugen" zonder daarbij te kijken naar alle andere performance data.