Re: Strange memory allocation behaviour

[James Henstridge <james daa com au>]

It is probably due to things like GList structures.  If you look at the
GList code in glib, you will see that it never frees a GList structure
(unless you use list allocators or something).  The idea is that in steady
state, no new GList structures will be allocated.

My guess is that in your code you are seeing this sort of thing, so the
memory usage increase decreases as the program runs.

Of course I could be wrong, and there is a leak or two ...

James.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/


On Sun, 28 Nov 1999, Bjorn Andersson wrote:

> Earlier I asked about GnomeDialog and memory allocation. I claimed
> that 8kB of memory was allocated and not freed each time I opened and
> closed the dialog. I wanted to test how fast I would run out of memory,
> so I modified my test code to automatically close the dialog with a
> timeout callback. I ran it with memprof and the result is interesting:
> 
> To start with memprof reports about 164 kB of memory in 4000
> allocations. The number of allocated bytes first increase linearly
> (related to time) to about 900 kB (in 9500 allocations) where the
> allocation speed starts to retard. At 1006 kB allocation is realy slow,
> but still increasing. Obiously the allocated memory is not linearly
> related to the number of times the dialog is open and closed. But
> why this behaviour? Can anybody explain?
> 
> Here is the code I used. If you don't have memprof, ps works just
> as well to examine the behaviour.
> 
> Regards,
> Björn Andesson
>