RE: [gtk-list] Re: Benchmarking glib (atleast GList) (was: how ca n I trust glib when it has so many memleaks?)

["Rostedt, Steven" <steven rostedt lmco com>]

	[You cheated! Your own g_list_append() function really does a
g_list_prepend(),
> which is much faster.
> 
> If I use the real g_list_prepend() the results look quite different:]
> 
	You're right! A thousand whips with a wet noodle for me :(  That's
what I get
	when I try to do something in a hurry late Friday night!
	I keep forgetting to use prepend instead of append.
	Which is another discussion all together. (I submitted an GQList
that
	encapsulated the GList that allowed efficient adding to the end, 
	but nobody wanted it :(  ).

	Anyway, My statement about the 2 day time compared to a 1 1/2 hour
	time was true. But I did use 1.0.6 for that. Was there any
improvements
	for 1.2?

	I'm starting to write some generic libraries and I'm still a little
leery about
	using GList (with prepend ;).  

	I also would like to see a way to flush the memory that is used. 
	If this is being used for a daemon that never shutsdown. It may
	not be nice of that daemon to take a lot of resources during a heavy
	crunch, but never free them during a light period.

	I've written another benchmark case  <<testglib.tgz>> 

	I used prepend instead of append to make sure I do
	this correctly.  The results are that the glib version 
	has better utime, stime, and seems better with the numbers
	but watching this running "top" I observed that the glib version
	was using close to 28 Megs of memory and my version
	never reached 10 Megs. This is critical since my machine
	only has 32 Megs of actually memory.  The glib version 
	had 271,110 page swaps, while my version only had 8!

	The difference of this test was it has  two loops.
	One that goes from 1 to i, and then frees
	the glist, then goes from i*2 to i.

	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.  

	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.

testglib.tgz