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

[Damon Chaplin <damon karuna freeserve co uk>]

"Rostedt, Steven" wrote:

> 
>         [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 :(  ).

I don't like the current implementation of GList much either. I'd like to
see a better one which remembered the tail and you didn't have to keep track
of the head yourself (it would make handling radiobutton groups easier as
well!). But a lot of code uses GList.


>         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!

I'm not sure your benchmark program is that useful.
It seems to be benchmarking the Linux kernel to see how fast it is at
allocating and reclaiming memory to/from a process. That is what is
taking the most time! (and that's why the noglibtest stime was so big.)

I changed the GLib case to using a GAllocator, and it got much slower
(as it now keeps releasing lots of memory back to the kernel, I presume).


Damon