[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Question - using --enable-fast-malloc=full
From:       Lubos Lunak <l.lunak () email ! cz>
Date:       2002-04-13 19:09:59
[Download RAW message or body]

On so 13. duben 2002 04:23, Marc Espie wrote:
> In article <3CB60510.7080905@yahoo.com> you write:
> >Lubos Lunak wrote:
> >>On Thu 11. April 2002 17:36, Pavel Troller wrote:
> >>>Hi!
> >>>  I recently tried the configure option noted in the subject and it's
> >>>really a sort of Turbo Switch (TM)! At least system startup speed and
> >>>konqueror/khtml are really faster now!
> >>>  What I'm asking: this option is present in kdelibs. After recompiling
> >>>kdelibs with it will the fast malloc be used by all the packages
> >>>automatically, or should they be recompiled first to use it ?
> >>>                                              With regards, Pavel
> >>> Troller
> >>
> >> Just rebuilding libkdecore is enough.
> >
> >What is the disadvantage of that compile option?
> >Cheers
> >F@lk
>
> Doesn't buy you anything on some systems, either because they don't support
> threads, or they have another malloc entirely.
>
> In fact, this is fairly tied to glibc. If you don't have the glibc, it uses

 No, it's not, --enable-fast-malloc=full should work on all systems, for which 
a spinlock implementation is available (right now only for x86, but I can 
find and add more if there's interest). Glibc is needed only when =full is 
not given, and using --enable-fast-malloc without =full makes sense only one 
wants to have it configurable at runtime (e.g. for debugging, or when one 
doesn't trust it entirely ;) ).

> its own malloc. And some systems may have another malloc, that works faster
> than that specific malloc...

 That's the point, using own implementation of malloc (and the fastest one I 
could find - I actually doubt there can be a faster one).

>
> This is what I experienced on OpenBSD. fast-malloc is not any faster than
> the default malloc, and it's even a bit slower.

 Not in my small test. 
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/malloc.c needed 
almost double the time kdecore/malloc needed (hopefully the same conditions, 
even though maybe I missed some important option for openbsd malloc). Looking 
at the source also doesn't make me think it's the fastest malloc in the 
world.

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli



 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]