🚀 go-pugleaf

"Ramon Smits" <exyll@hotmail.com> wrote in message
news:3f6c1dd6$0$135$e4fe514c@dreader4.news.xs4all.nl...
> Serve La wrote:
>
> >>De garbage collector gaat pas ruimen nadat er daadwerkelijk het systeem
> >>bijna geen fysiek vrij geheugen meer is
> >
> > Dat vind ik nogal moeilijk te geloven en dat gedrag zie ik ook helemaal
niet
> > in een testprogje van mij.
>
> Tsja... low on memory misschien :). Wat doet je test applicatie om dit
> na te bootsen?

in een timer event geheugen alloceren. Ik zie geen vollopen van het geheugen
tot het bijna vol is (gelukkig)

> > Dat wil nog niet zeggen dat alle programma's ineens asociaal veel
geheugen
> > moeten gebruiken.
>
> Dat zeg ik ook niet :). It's all about design. Waarom een object continu
> creeeren en destroyen als je weet dat je die actie per uur 1 miljoen
> maal moet doen. Dan is het nuttig dergelijke objecten te cachen. Maar
> dat is eigenlijk altijd al geweest.

Wat ik bedoelde is dat al die programma's wel ergens geheugen alloceren. Als
een GC zo werkt dat ie op gaat ruimen als het fysieke geheugen vol is heb je
nog steeds een traag systeem ondankds dat je 512/1024mb hebt. Maar zo werkt
de .NET GC ook niet.

> Inderdaad een bulk aan applicaties die veel geheugen nodig hebben. Maar
> dat zijn piek momenten. Je tekstverwerken is niet continu met een
> spellingscontrole bezig en je ontwikkelomgeving niet continu aan het
> compileren en je tekenprogramma niet continu een batch aan
> beeldbewerkingen. Als een applicatie veel geheugen nodig heeft wil dit
> niet zeggen dat die applicatie dat geheugen ook continu nodig heeft. Zet
> anders maar eens 30 applicaties open met data. Je zult zien dat de
> applicatie die de focus heeft gewoon goed performed ondanks dat je
> systeemgeheugen toch echt op is.

Maar dat heeft allemaal niks met GC te maken, meer met virtueel geheugen.