Re: [gtk-list] GMemChunk for skip lists

[Tim Janik <timj gtk org>]

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

---
ciaoTJ

Date: Sat, 26 Jun 1999 16:54:40 +0200 (CEST)
From: Tim Janik <timj@gtk.org>
Reply-To: gtk-app-devel-list@redhat.com
To: yarick@yarick.relex.ru
Cc: Gtk+ Application MList <gtk-app-devel-list@redhat.com>
Subject: Re: Glib memory handling
Resent-Date: 26 Jun 1999 16:27:48 -0000
Resent-From: gtk-app-devel-list@redhat.com
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.

---
ciaoTJ

From: Tim Janik <timj@gtk.org>
Message-Id: <199903222157.WAA27708%timj@gtk.org>
Date: Mon, 22 Mar 1999 22:57:57 +0100 (CET)
To: "'gtk-list@redhat.com'" <gtk-list@redhat.com>
In-Reply-To: <99AA2270B1E6D111BCE10000F805F17F010A1855@emss35m02.owg.fs.lmco.com>
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.
> 

---
ciaoTJ