This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: about glibc performance
- From: "Paul Pluzhnikov via libc-help" <libc-help at sourceware dot org>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: "Carlos O'Donell" <codonell at redhat dot com>, Jimmie <zpjjimmie at 163 dot com>, libc-help <libc-help at sourceware dot org>
- Date: Fri, 22 Mar 2019 08:48:07 -0700
- Subject: Re: about glibc performance
- References: <4aa1551b.86a8.169a3699c45.Coremail.zpjjimmie@163.com> <f48a9b4a-b478-518a-47ee-6ad3e4ab9872@redhat.com> <CAAHN_R3+KwFZQ9cD93yh7oJ0WS-qVThv=2f+AubgSZV-erjtCQ@mail.gmail.com>
- Reply-to: Paul Pluzhnikov <ppluzhnikov at google dot com>
On Fri, Mar 22, 2019 at 6:56 AM Siddhesh Poyarekar
<siddhesh.poyarekar@gmail.com> wrote:
> I've argued in the past
> that the per-thread allocator should bring performance of a number of
> applications on par if not better than tcmalloc/jemalloc, but I never
> did a formal run and so never wrote a formal rebuttal of the tcmalloc
> claims.
The claims you didn't formally rebut are probably these:
http://goog-perftools.sourceforge.net/doc/tcmalloc.html
Note that that document is from 2005, and talks about benchmarking
against GLIBC 2.3 on Intel P4 processors in 32-bit mode.
It's not like TCMalloc has stood still for the last 15 years, but I
don't believe there have been any recent open-source releases of it.
--
Paul Pluzhnikov