From kde-core-devel  Thu Feb 14 19:43:09 2002
From: Allan Sandfeld Jensen <snowwolf () one2one-networks ! com>
Date: Thu, 14 Feb 2002 19:43:09 +0000
To: kde-core-devel
Subject: Re: malloc performance
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101379219532600

On Thursday 14 February 2002 20:30, Lubos Lunak wrote:
> On Thu 14. February 2002 19:47, Alex Zepeda wrote:
> > On Thu, Feb 14, 2002 at 07:43:17PM +0100, Lauri Watts wrote:
> > > I already asked PHK, and while I don't think ability is at question,
> > > time is.
> >
> > Errr.. I was referring to the present phkmalloc featured in libc.  AFAIK
> > it's quite a bit more optimized than what's in glibc.
>
>  Yes, it's better than the one in glibc-2.2.x, but not as good the one that
> will be in glibc-2.3 (at least according to some tests Lauri did).
>
> > > He says there is no objection to us implementing it internally, and
> > > said it's probably a good idea, at least for now.
> >
> > I'd still like to see some becnhmarks tho.
>
>  Feel free to try yourself, just do what I did. Download
> http://dforce.sh.cvut.cz/~seli/download/malloc.tar.bz2 ,  do 'make lealib',
> and run e.g. Konqueror, once normally, once with the library LD_PRELOAD-ed.
> Then go to some large HTML page, e.g. $QTDIR/doc/html/functions.html and
> measure the time between hitting Reload and when the page is finished.
> Unless you have a fast computer, you wristwatch may be enough to see the
> difference.

Hmm... Just a note on malloc performance.

Classically speaking a system like KDE or rather Qt, that mallocs a lot of 
small object and has it's own object system should be _alot_ faster with a 
garbage collection strategy. Now this could be done in two ways, the elegant 
way where you only garbage collect on our own pointertype by linking them in 
a list. And doing sweeps marking all (q)objects they point at, and freeing 
the rest. Or the more intrusive way of implementing a cheap malloc and empty 
free, and then scanning the entire memory for something that look like a 
pointer again marking the areas they point at. Even the later strategy has 
been proven to be faster than all accurate malloc/free implementations.

Ofcouse the trade-off is that  between sweeps a garbage collecting strategy 
will waste _some_ amount of memory.

greetings
Allan