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 <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Gtk+ Application MList <[EMAIL PROTECTED]>
Subject: Re: Glib memory handling
Resent-Date: 26 Jun 1999 16:27:48 -0000
Resent-From: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Date: Mon, 22 Mar 1999 22:57:57 +0100 (CET)
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
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
--
To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
