This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: about glibc performance
There have been about 80 patches which modify files in the
malloc directory of the glibc src tree between 2.17 and 2.28.
2.17 was first available around 2013 and 2.28 in 2018.
Many fixes are minor, some are not. They include fixing race
conditions, fixing boundary condition computations, and
some are performance improvements.
For the performance improvements, in addition to offering
the thread-based allocation areas, glibc malloc has also
improved the code to decide when to return memory to the
system, reducing the thrash-effect of frequent small and
medium malloc/free combinations. That is a significant benefit
for C++ and Java programs that are written in a style
which does frequent "new/allocate and free" operations.
At least one of the SPEC cpu2017 benchmarks benefits
from this improvement.
Whenever comparing malloc replacements, be sure you
have recent versions of the allocators as there has
been considerable activity in improvement of several
of these allocators over the last 5-10 years.
On 3/22/2019 9:53 AM, Carlos O'Donell wrote:
On 3/22/19 9:55 AM, Siddhesh Poyarekar wrote:
On Fri, 22 Mar 2019 at 09:08, Carlos O'Donell <codonell@redhat.com>
wrote:
On 3/21/19 11:20 PM, Jimmie wrote:
Hi, For serveral days, I did some test about the memory performance
of glibc(2.17) and tcmalloc(gperformance 2.7), and my test results
indicate that glibc is more efficient then tcmalloc. generally,
people think tcmalloc is efficient than glibc 2.3, but I use glibc
2.17, so I wonder if glibc 2.17 did some improvement on memory
performance. looking forward to your reply, thank you.
There were no changes in 2.17 which improved malloc performance.
Actually, there were performance improvements to malloc between 2.3
and 2.17, primarily the per-thread allocator that greatly reduced
contention for multi-threaded applications. 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. If you've done formal tests, please do publish them!
Oh, right, certainly in 2.15 we switched on per-thread allocators!
I forgot all about that. And from 2.10 to 2.15 it could have been on
with --enalbe-experimental-allocator.