This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: malloc() and spinlocks
On Tuesday 26 November 2002 15:04, Wolfram Gloger wrote:
> > I don't want to break anything. I just want something like this - see
> > the thread-m.h.patch attachment. I don't know if the code should be
> > duplicated or if the spinlock code is not necessary in the not _LIBC
> > part.
>
> In the patch for thread-m.h which I just sent, there is no code
> duplication. Please try it out.
Will do.
>
> > The
> > mallo.c.patch is for __inline__ - I don't know if you even want to apply
> > that, and I doubt it can go in in this form (having simply __inline__
> > there), I simply added a couple of __inline__ where I liked :).
>
> I really see no point in this, see below.. Your inline patch would
> only cause code size explosion and no real benefit.
In the patch I attached I simply put __inline__ in all places where it seemed
to make at least some difference. If I tried to find places only where really
necessary, I'd inline only those functions on the shortest paths. I didn't
know those are exported :(. Adding those inline's reduced the time to 90% for
me (only when looping and calling malloc/free). In the malloc in KDE
(http://kdewebcvs.pandmservices.com/cgi-bin/cvsweb.cgi/kdelibs/kdecore/malloc/),
I also used inline's at the expense of somewhat larger code size.
Anyway, I don't insist on this. It doesn't make much difference if this
malloc will make KDE apps run 3% or 4% slower then the one in libkdecore. As
long as it doesn't make them run almost twice as slow because of the slow
mutexes, it's fine.
--
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/