Re: [gtk-list] GMemChunk for skip lists

On Fri, 3 Mar 2000, Derek Simkowiak wrote:

> 	Also, what is the point of a GAllocator?

excessive temporary use of a certain structure type.
explainatory email from archives appended, probably
and FAQ candidate.

> Thank You,
> Derek Simkowiak


Date: Sat, 26 Jun 1999 16:54:40 +0200 (CEST)
From: Tim Janik <>
Cc: Gtk+ Application MList <>
Subject: Re: Glib memory handling
Resent-Date: 26 Jun 1999 16:27:48 -0000
Resent-cc: recipient list not shown: ;

On Sat, 26 Jun 1999, Yarick Rastrigin wrote:

> well, could someone clear some points for me ?
> I'm writing an app, which in turns creates quite large GList' s. 
> I'm monitoring memory usage with qps. App requests and gets 8 Mbytes of
> memory for it's purposes, after processing lists are freed with all
> their contents. Howewer, data size of my app isn't decreased when all
> done. How I could really free unnecessary memory ? Or this isn't
> gtk/glib feature, but libc-related one ?
> -- 

glib usually keeps list nodes around because it makes the basic assumption
that a program's list node usage stays approximately the same throghout
a programs life time.
if you require a huge amount of nodes for a certain time only, and you
know you better free them later on again, you need to use allocators.
appended is an old mail of mine which briefly describes allocator usage.


From: Tim Janik <>
Message-Id: <>
Date: Mon, 22 Mar 1999 22:57:57 +0100 (CET)
To: "''" <>
In-Reply-To: <>
Subject: [gtk-list] Re: Benchmarking glib (atleast GList) (was: how ca
 n I trust glib when it has so many memleaks?)

On Mon, 22 Mar 1999, Rostedt, Steven wrote:

> 	I believe we ARE getting memory fragmentation
> 	here!  This test makes a large allocations after 
> 	the glists have been made, and these allocations
> 	do not fit in the segments that have been previously
> 	available.
> 	This is why I think it is critical to have an actual 
> 	free call that frees all the buffered lists.  There
> 	are times when large amounts of data needs
> 	to be allocated and will surpass the size
> 	of the memory chunks.  

if you have a certain portion of code that uses *lots* of GLists or
GNodes, and you know you'd better want to release all of them after
a short while, you'd want to use a GAllocator. pushing an allocator
into g_list will make all subsequent glist operations private to that
allocator's memory pool (and thus you have to take care to pop the
allocator again, before making any external calls):

GAllocator *allocator;
GList *list = NULL;
guint i;

/* set a new allocation pool for GList nodes */
allocator = g_allocator_new ("list heap", 1024);
g_list_push_allocator (allocator);

/* do some list operations */
for (i = 0; i < 4096; i++)
  list = g_list_prepend (list, NULL);
list = g_list_reverse (list);

/* beware to pop allocator befor calling external functions */
g_list_pop_allocator ();
gtk_label_set_text (GTK_LABEL (some_label), "some text");

/* and set our private glist pool again */
g_list_push_allocator (allocator);

/* do some list operations */
g_list_free (list);
list = NULL;
for (i = 0; i < 4096; i++)
  list = g_list_prepend (list, NULL);
/* and back out (while freeing all of the list nodes in our pool) */
g_list_pop_allocator ();
g_allocator_free (allocator);

> 	Conclusion: This test I believe demonstrates
> 	why my application when so long, and why
> 	there should be a g_list_flush function.
> 	I would write it but I don't know all the details
> 	of how the chunks in the Glist are allocated.
> 	I looked at the code and have a good idea,
> 	but I don't want to assume anything :)
> 	Steve.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]