Re: [gtk-list] Re: Benchmarking glib (atleast GList) (was: how can I trust glib when it has so many memleaks?)
- From: Tim Janik <timj gtk org>
- To: "'gtk-list redhat com'" <gtk-list redhat com>
- Subject: Re: [gtk-list] Re: Benchmarking glib (atleast GList) (was: how can I trust glib when it has so many memleaks?)
- Date: Mon, 22 Mar 1999 22:57:57 +0100 (CET)
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]