Re: [gtk-list] Re: Benchmarking glib (atleast GList) (was: how can 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



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