Re: [gtk-list] Excessive Memory Usage in Clist and Text

[Havoc Pennington <hp redhat com>]

On Fri, 10 Sep 1999, Matthew wrote:
> only as many rows as specified by the limit.  However, even though
> there are far fewer rows (2000 as opposed to 20000) the Clist still
> uses the same amount of memory.  It's as if the remove doesn't free
> the memory used by that row.  Is this true?
> 

It's possible but you don't care as much as you might think. There are
multiple interacting factors:

 - some malloc()/free() implementations never free memory back to the 
   system until the program exits, they only recycle it within the process
 - glib does some similar recycling for speed reasons, but the glib
   recycling is for "all linked lists in a process" or the like. 
   This memory won't have free() called.
 - as I understand it even malloc()/free() implementations that do free
   memory back to the system may not do so in every instance; for
   example memory is normally requested and released in chunks, if
   malloc() then gives you that memory in smaller bits you have to free all 
   the small pieces before the big piece goes back to the system. 

Of course it's also possible that clist has a memory leak and it would be
good to track that down.

The thing is, you don't care very much, because if you stop using a big
hunk of memory it will just be swapped out and ignored, the user's
physical RAM will be made available.

On the whole Windows and MacOS have trained people to pay way too much
attention to memory. :-)

Havoc