This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Malloc improvements


Hmmm... not sure why that test case is worse in my branch, the whole
point of my work is to add a lockless fast path.  I'll have to
investigate that some more.  Conveniently, I have a trace feature in
there that I'm also working on ;-)

But yeah, we know there's a lot of unneeded overhead in glibc's malloc,
and that other mallocs can do better.  Glibc's malloc itself states that
it's not trying to be the best at one task, but the best usable
compromise.  Part of what I'm doing is understanding where these
compromises cause significant performance problems, and seeing if we can
find other ways to solve them without just replacing it with something
else.

Also, of course, obligatory note... your test case is not a typical
application.  We're trying to come up with a way of modelling real
applications and benchmarking those, instead of relying on trivial test
cases to "represent" the real world.  A change that is worse in a test
case might be better for real apps, and visa-versa.

I've also done some work on micro-benchmarking of malloc, see
http://developers.redhat.com/blog/2016/03/11/practical-micro-benchmarking-with-ltrace-and-sched/
(just to show that I'm really working on this problem ;)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]