Benchmarking glib (atleast GList) (was: how can I trust glib when it has so many memleaks?)
- From: Steven Rostedt <steven rostedt lmco com>
- To: gtk-list redhat com, steven rostedt lmco com
- Subject: Benchmarking glib (atleast GList) (was: how can I trust glib when it has so many memleaks?)
- Date: Fri, 19 Mar 1999 13:15:40 -0500
I've attached a tar gziped program with both
a Makefile and a testglib.c.
I noticed once before that a program of mine took 2 days to run and
allocated 170 Megs!!! to convert a 60 Meg database from one format
to another database format. This code implemented GList.
I rewrote the GList code to free all its lists and it only took
1 and a half hours to run and a total of 89 Meg of memory.
To simulate this I wrote a test program to benchmark GList.
Instead of having an argument about who does what better,
please down load this, compile and run it. And see for
your self what is better.
This produces two programs "glibtest" and "noglibtest".
The glib test uses the GList from glib and the noglibtest
uses my own.
Look at the code, its short :) and then report back on
what you think.
Please note I ran this with glib-1.2.0 on Slackware Linux
with Kernel 2.2.3. I made no effort for portability.
These were my results:
glibtest:
utime = 4:530000
stime = 0:160000
shared mem size = 0
unshared data size = 0
unshared stack size = 0
page reclaims = 746
page faults = 378
swaps = 0
block input = 0
block output = 0
noglibtest:
utime = 1:290000
stime = 1:180000
shared mem size = 0
unshared data size = 0
unshared stack size = 0
page reclaims = 30910
page faults = 67
swaps = 0
block input = 0
block output = 0
Please Note the user time "utime"
Steve.
testglib.tgz
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]