Re: [gtk-list] Re: how can I trust glib when it has somanymemleaks?

[Ulric Eriksson <ulric edu stockholm se>]

On Thu, 18 Mar 1999, Ionutz Borcoman wrote:

> Lars Hallberg wrote:
> > 
> > Possably g_mem_profile() can differntiate between memmory that is
> > allocated but 'free' or internaly used an memory allocated by
> > the users code? If not, that is probably the right spot to hack
> > glib..... Best luck ;-)
> 
> See above. g_mem_profile can't handle all the cases. A function like
> free all glib memory would be the best thing. 

Regarding this memory allocation problem, and the claim that leaving it to
malloc would be slow: has anyone actually profilled it, and are there any
numbers to support the claim?

Below is a braindead program which calls malloc and free 1000000 times. It
takes 7 seconds to run on my Ultra 1 (Solaris 2.5.1), 18 seconds on a
Sparc 4 under Linux and 9 seconds on a P133, also Linux.

My guess is that any program that also does anything useful spends
insignificant time on memory allocation. The argument that glib can do a
better job of keeping the memory localized holds more weight. Some actual
figures would be nice to see for that as well. Also, one cannot help but
think that glib's strategy may just as well result in memory being
localized WRT the OS but fragmented within glib itself.

Ulric

8<------

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
        long i;
        void *p[16];
        clock_t t, t0 = clock();
        int ti;

        for (i = 0; i < 16; i++) p[i] = NULL;

        for (i = 0; i < 1000000; i++) {
                int r = rand();
                int n = r & 15;
                int m = r & 32767;
/*printf("%d bytes into bucket %d\n", m, n); */
                free(p[n]);
                p[n] = malloc(m);
                if (p[n] == NULL) fprintf(stderr, "Eek!\n");
        }
        t = clock();
        ti = (t-t0)/CLOCKS_PER_SEC;
        printf("%d seconds\n", ti);
        return 0;
}