Benchmarking glib (atleast GList) (was: how can I trust glib when it has so many memleaks?)



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]