malloc() and spinlocks

[Lubos Lunak <l dot lunak at suse dot cz>]

 Hello,

 glibc-2.3 was supposed to have faster malloc() implementation than glibc-2.2, 
partially because of basing on newer version of Doug Lea's malloc(), 
partially because of using spinlocks instead of mutexes for the locking (see 
also http://sources.redhat.com/ml/libc-alpha/2002-02/msg00107.html). However, 
with glibc-2.3.1-20021107 , KDE compiled with its own malloc() still performs 
noticeably faster than when using the glibc one.

 It looks like the newer malloc() version is in, which results in slightly 
better performance than glibc-2.2. I even see the spinlock code in 
glibc/malloc/thread-m.h , but the placement of that code is somewhat ... 
unfortunate. If you look carefully, you'll notice it's placed in #else part 
of #if defined(_LIBC). After moving that code, and adding a couple of 
__inline__'s , that malloc() finally performs at least comparably to the KDE 
one. Well, it was actually still about 2-5% slower when viewing a very large 
HTML page in Konqueror, but I guess we can live with that. I'm not very keen 
on the idea of the default malloc() implementation being optimalized for the 
rare case of many threads extensively using the heap or having debug stuff in 
it (=hooks), on the other hand having another malloc in libkdecore causes 
some trouble in special cases :(.

 Could somebody please modify malloc/thread-m.h so that the spinlocks are used 
when possible? Adding __inline__ to functions on the most often executed 
paths and raising -finline-limit for gcc could help a little too, but the 
spinlocks are the thing makes the huge difference. I hope this will get into 
the next stable glibc release.

 Thanks
 
-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/