Re: ghashes

[James Henstridge <james daa com au>]

On Wed, 28 Mar 2001, Christoffer Gurell wrote:

> > i see a problem in ghash.c. Mem is allocated from a global GMemChunk which
> > never shrinks.. say a preogram spawns 20threads that all create one hash
> > each. then ALOT of memory will be allocated and never freed.. a solution
> > could be to move the GMemChunk into the GHashTable stuct so that each hash
> > has it's own mempool.. this would enable g_hash_table_destroy() to free ALL
> > memory associated with a ghash so no memory leaks .. 
> 
> i've done some mem profiling and indeed with many hashes of large hashes
> dmalloc reports a whole bunch of allocations of mem that are never freed..
> i've patched my version and put the allocator inside the GHashTable struct
> so that each hash has it's own allocator. i could then remove the lock in
> ghash.c since there are no longer any global variables. :) . problem is that
> if i have a very larga hash it takes TIME to free the allocator when the
> hash i destroyed..  this can be helped by allocating 10000 instead of 1024
> but this is'nt always desired either.. perhaps we should make it possible to
> tell the ghashed how many key's we think it'll hold.. or perhaps make the
> allocator allocate more mem each time it needs to..   

Isn't the point of having the global allocator so that the hash nodes
could be reused, resulting in less allocations over all?  I believe that
the current behaviour is a design decision -- not a fault.

James.

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