Re: [gtk-list] Re: GAllocator vs. g_free (was: GMemChunk for skiplists)

[Tim Janik <timj gtk org>]

On 9 Mar 2000, Havoc Pennington wrote:

> 
> Derek Simkowiak <dereks@kd-dev.com> writes: 
> > 	I have recently learned that free() (or g_free() ) does not return
> > the freed memory to the operating system until after the program is
> > killed.  So if I g_malloc() a ton of memory, and then g_free() it, my
> > program is still using a crapload of RAM until it is killed.
> > 
> > 	Is it any different with a GAllocator?  I.e., if I need to
> 
> Yes, because mem chunks can only be recycled for allocations of the
> same type/size, while memory allocated by malloc() can be recycled for
> any future malloc(). This is why mem chunks are theoretically faster,
> because you can simply pop the top free chunk off a stack, instead of
> trying to find a free chunk of the right size. However in practice GNU
> libc malloc() can find a free chunk about as fast as glib's mem chunk
> stuff can, because GNU libc malloc() is an insanely scary
> hyperoptimized thing.

that's right. though there are two things to consider here, memchunks
may undergo some optimizations in the future (ways to improve the
btree performance used for the memchunk implementation have already
been pointed out on gtk-devel-list), and not every platform that gtk and
glib run on actually come with GNU malloc. so using memchunks is often
a wise decision, both currently and for the future.

> 
> Havoc
> 

---
ciaoTJ